Limitation
When an [ID] field declares an explicit type name via the attribute ([ID("Booking")]), we validate that an incoming global id actually belongs to that type — a global id for a different type is rejected, matching Hot Chocolate's built-in behaviour.
This validation is not applied to the fluent form descriptor.Field(x => x.Id).ID("Booking"). Fluent ids are still fully handled (raw db ids and global ids both work via #5), but a global id of the wrong type won't be rejected on a fluently-declared field.
Why
For the attribute form we read the type name straight off IDAttribute.TypeName. For the fluent form, the string passed to .ID("Booking") isn't on the CLR member or the field configuration — Hot Chocolate captures it inside its own GlobalIdInputValueFormatter instance (along with a validateTypeName flag). Because we replace that formatter (to accept raw db ids and to control list/null handling), we'd have to recover the name to validate it ourselves.
Options if there's demand
- Reflection — read the captured
name/validateTypeName off HC's formatter instance (which we already hold when we replace it) and feed them into our formatter. Brittle: that formatter uses a C# primary constructor, so the captured fields have compiler-generated names, and it's reading HC internals that can change between versions.
- Delegation — keep a reference to HC's formatter and hand global ids to it (so HC parses + validates with the real name, for both attribute and fluent) while we special-case raw db ids so they bypass it. No reflection; minor caveat that a wrong-type global id string on a
string-typed field would be treated as a raw db id rather than rejected.
Workaround
Use the [ID("Booking")] attribute instead of .ID("Booking") if you need the type-name check.
👍 this issue if you'd like fluent fields validated too.
Limitation
When an
[ID]field declares an explicit type name via the attribute ([ID("Booking")]), we validate that an incoming global id actually belongs to that type — a global id for a different type is rejected, matching Hot Chocolate's built-in behaviour.This validation is not applied to the fluent form
descriptor.Field(x => x.Id).ID("Booking"). Fluent ids are still fully handled (raw db ids and global ids both work via #5), but a global id of the wrong type won't be rejected on a fluently-declared field.Why
For the attribute form we read the type name straight off
IDAttribute.TypeName. For the fluent form, the string passed to.ID("Booking")isn't on the CLR member or the field configuration — Hot Chocolate captures it inside its ownGlobalIdInputValueFormatterinstance (along with avalidateTypeNameflag). Because we replace that formatter (to accept raw db ids and to control list/null handling), we'd have to recover the name to validate it ourselves.Options if there's demand
name/validateTypeNameoff HC's formatter instance (which we already hold when we replace it) and feed them into our formatter. Brittle: that formatter uses a C# primary constructor, so the captured fields have compiler-generated names, and it's reading HC internals that can change between versions.string-typed field would be treated as a raw db id rather than rejected.Workaround
Use the
[ID("Booking")]attribute instead of.ID("Booking")if you need the type-name check.👍 this issue if you'd like fluent fields validated too.