Found while rewriting the INVALID_FIELD block of content/docs/protocol/kernel/error-handling.mdx for #15800 (that card's scope is that one block; error-catalog.mdx is explicitly out of scope there, so this is filed rather than fixed).
⛔ Ungraded and unrouted — domain:*, priority and type are triage's. Filed unassigned by an os-dev seat.
The gap
content/docs/api/error-catalog.mdx:71 publishes INVALID_FIELD's Cause as a field NAME that does not exist on the target object, and enumerates the read axes it covers, including:
searchFields (a real field outside the searchable set gets its own message)
Two producers raise INVALID_FIELD on the searchFields axis for a condition that enumeration does not describe — the parameter's own value shape, not a name that fails to resolve:
packages/metadata-protocol/src/protocol.ts:9610
`'<param>' entry #<n> on object '<object>' is not a field name. `
+ `'<param>' narrows which columns 'search' scans, as a comma-separated string or an array of field names.`
packages/metadata-protocol/src/protocol.ts:9624
`'<param>' on object '<object>' must be a comma-separated string or an array of field names, `
+ `received <typeof value>. ...`
Both set code = 'INVALID_FIELD', status = 400, and param (not field). The first fires when an array entry is not a string; the second when the parameter is neither a string nor an array.
Why it is worth a row
These are the only two of the 22 repo-wide INVALID_FIELD assignment sites that refuse a value shape rather than an unresolvable name. An integrator reading the catalog's Cause has no way to predict them, and an operator who hits one reads a Cause text describing a different condition. They are also the sites most likely to be mistaken for the meaning #15800 removes from error-handling.mdx («Field value has wrong type») — so leaving them undocumented keeps a fragment of that removed meaning alive with no published home.
The shape is still field-name-flavoured: the value being refused is a list of field names. This is a coverage gap in one clause of the Cause text, not a second meaning for the code, and ⛔ no claim is made here that the runtime code choice is wrong.
Two ways to close it (⛔ not decided here)
- A — extend the catalog's
searchFields clause to name the shape refusal alongside the outside-the-searchable-set refusal. One clause, no code change.
- B — leave the catalog alone and treat the shape refusal as belonging to another code. That is a runtime contract change, needs an ADR-0112 reading, and is much larger than the observation.
A is the cheap reading; the measurement above does not settle which is right, so this is filed unassigned and ungraded for triage.
Re-check
git grep -nE "code(: | = )'INVALID_FIELD'" -- 'packages/**/*.ts' ':!**/*.test.ts' # 22 sites / 5 files
sed -n '9604,9630p' packages/metadata-protocol/src/protocol.ts
sed -n '71,80p' content/docs/api/error-catalog.mdx
Dedup: one semantic search_issues for this condition returned 4 issues, all closed and all about a different defect (#7534, #6897, #6674, #4830); no open card names this gap.
Related: #15800 (the error-handling.mdx block this was found under), ADR-0112, ADR-0114.
Found while rewriting the
INVALID_FIELDblock ofcontent/docs/protocol/kernel/error-handling.mdxfor #15800 (that card's scope is that one block;error-catalog.mdxis explicitly out of scope there, so this is filed rather than fixed).⛔ Ungraded and unrouted —
domain:*, priority and type are triage's. Filed unassigned by anos-devseat.The gap
content/docs/api/error-catalog.mdx:71publishesINVALID_FIELD's Cause as a field NAME that does not exist on the target object, and enumerates the read axes it covers, including:Two producers raise
INVALID_FIELDon thesearchFieldsaxis for a condition that enumeration does not describe — the parameter's own value shape, not a name that fails to resolve:Both set
code = 'INVALID_FIELD',status = 400, andparam(notfield). The first fires when an array entry is not a string; the second when the parameter is neither a string nor an array.Why it is worth a row
These are the only two of the 22 repo-wide
INVALID_FIELDassignment sites that refuse a value shape rather than an unresolvable name. An integrator reading the catalog's Cause has no way to predict them, and an operator who hits one reads a Cause text describing a different condition. They are also the sites most likely to be mistaken for the meaning #15800 removes fromerror-handling.mdx(«Field value has wrong type») — so leaving them undocumented keeps a fragment of that removed meaning alive with no published home.The shape is still field-name-flavoured: the value being refused is a list of field names. This is a coverage gap in one clause of the Cause text, not a second meaning for the code, and ⛔ no claim is made here that the runtime code choice is wrong.
Two ways to close it (⛔ not decided here)
searchFieldsclause to name the shape refusal alongside the outside-the-searchable-set refusal. One clause, no code change.A is the cheap reading; the measurement above does not settle which is right, so this is filed unassigned and ungraded for triage.
Re-check
Dedup: one semantic
search_issuesfor this condition returned 4 issues, all closed and all about a different defect (#7534, #6897, #6674, #4830); no open card names this gap.Related: #15800 (the
error-handling.mdxblock this was found under), ADR-0112, ADR-0114.