0.9.8, Blazor .NET 7 and EF Core.

I have a model, Lines, with a scalar navigation property, Item.
The model has a primary key comprising 7 properties and 3 of those properties make up a foreign key used when relating to the Item entity.
I retrieve a list of Lines via a Breeze query and multiple entities have the same 3 foreign key properties and thus should reference the same Item entity.

Two problems arise though :

  1. only one of these Line entities that should have the same Item actually have Item populated, the other Line entities have null (all other entities that do not share an Item are fine)
  2. saving changes to the list results in this error :
    “System.InvalidOperationException: ‘The instance of entity type ‘Line’ cannot be tracked because another instance with the key value ‘{BomHeaderID: 0-6 , Revision: , Type: product }’ is already being tracked. When attaching existing entities, ensure that only one entity instance with a given key value is attached.'”
  • BomHeaderID, Revision and Type are the three foreign keys relating to Item.

If the list of Lines only contains entities that do not share an Item then they all save successfully, but if even one double-up is present then entityManager.SaveChanges() fails.
The Item entity has no changes made to it, only basic properties on Line are changed.
The error still occurs even if I don’t expand the Item property or detach the Item entities after fetching!

I can make the save work by calling SaveChanges(new IEntity[] {thisRow}) one by one for each row in the Lines list, but this is a nasty hack to avoid using the same dbContext for all commits.

I realise this is an entity framework core error, but I am assuming something is going wrong with Breeze (perhaps in its JSON serialisation to the server?).

Any ideas welcome…

BTW, could someone explain to me where I should be getting the latest version of Breeze.Sharp from?
Nuget has version 0.9.8, while has 0.8.1 !!
Where is 0.9.8 coming from?
(Similar question for the other Breeze libraries, the version noted in the github repo doesn’t always match the one in Nuget).