Fix duplicate key crash when a service resolver builds an object from context members - #553

The bug

A service field whose resolver builds an object from two or more context members — as an argument to the service call — fails at compile time when that field is selected beneath another service field:

System.ArgumentException: An item with the same key has already been added.
   at System.Collections.Generic.Dictionary`2.Add(TKey key, TValue value)
   at EntityGraphQL.Compiler.Util.ExpressionReplacer..ctor(...)
   at EntityGraphQL.Compiler.BaseGraphQLField.ReplaceContext(...)

Surfaced to the caller as Field 'projects' - An item with the same key has already been added. Nothing is queried — the request fails during compilation. Originally hit on 6.2.1 in a production schema; reproduces on master.

Being below another service field is the precondition, not incidental: it is the only route that reaches the throwing line. Where the inner field also has a bulk resolver, EntityGraphQL logs Bulk resolver for field '…' was not used - it is selected below another service field and falls back to the per-item resolver, which then throws.

Root cause

Walking ExpressionExtractor over (user, srv) => srv.Get(new Project { Id = user.Id, Name = user.Field2 }):

1. VisitMethodCall pushes the call, visits node.Object (srv), finds nothing tied to the root context, pops.
2. ProcessPotentialLeaf gets the argument. It is a construction, not a member access, so the construction itself is pushed onto currentExpression and visited.
3. There is no VisitNew/VisitMemberInit override, so the base visitor descends into the constructor arguments or member bindings with the construction still on top of the stack.
4. VisitMember(user.Id) declines to push — the stack is non-empty, and IsNullableType() is false for int (it only means Nullable<T>) — so when VisitParameter recognises the root context it records currentExpression.Peek(): the construction, not the member.
5. user.Field2 takes the same path and derives the same name from the same construction's ToString(), so the extractor appends the identical node instance to the existing list, which is now [node A, node A].
6. That becomes one GraphQLExtractedField on ExtractedFieldsFromServices, built once at schema-build time.
7. Below another service field the bulk path is unavailable, so BaseGraphQLField.ReplaceContext builds an ExpressionReplacer, whose constructor called Add(exp, field) per expression. Expression does not override equality, so the second add of the same instance is a duplicate key.

ExpressionExtractor already documents the repeat as intentional:

We extract all expression - which may repeat - and we then replace them by matching the expression object

The replacer was the side that did not tolerate it.

The fix

One line — Add(exp, field) → [exp] = field. The replacer only ever reads this dictionary by identity, so a repeated entry is redundant rather than lost information.

Fixing it here rather than in the extractor matches the extractor's documented contract and has the smaller blast radius. A VisitNew/VisitMemberInit override in the extractor would change what every construction extracts, including the bulk key selectors and resolver bodies that work correctly today. Happy to take that route instead if you would prefer it.

Tests

Two, each in the file that owns its layer, both built from fixtures already in the suite (TestDataContext, UserService, ConfigService, Project, ProjectConfig) — no new types:

• ServiceFieldTests.TestServiceFieldWithNewInServiceCallArgUnderServiceField — end-to-end through the schema, beside the existing TestCollectionWithServiceUsingNewInExpression. Fails on master, passes with the fix.
• ExpressionExtractorTests.ExtractObjectBuiltFromMultipleMembersInMethodArg — no schema; pins the extractor behaviour the fix relies on, beside ExtractLongMemberExpressionSameNameInMethod. Passes either way by design, so that a later change to the extractor shows up here rather than quietly making the fix dead code.

Verification

net9.0 is in TargetFrameworks but that runtime is not installed here, so that TFM was not run locally.

Two unrelated notes from setting this up, happy to file separately or fix in this PR if useful:

• dotnet tool restore fails — .config/dotnet-tools.json names the command dotnet-csharpier, but csharpier 1.0.0 ships it as csharpier.
• dotnet test on the solution needs -p:NuGetAudit=false: SQLitePCLRaw.lib.e_sqlite3 has an open advisory and EntityGraphQL.EF.Tests / examples/demo promote NuGet warnings to errors.

🤖 Generated with Claude Code