isManagedFieldGuarded
isManagedFieldGuarded(
field,operation):boolean
Defined in: packages/contracts/src/registry.ts:542
Whether a managed field is SERVER-OWNED for an operation — the ONE definition of the guard rule, so the surfaces that enforce it cannot drift apart:
- create ⇒ the field is guarded when its
applyOnincludes"create". The server stamps it after validation, so a client value for it is never honoured. - update ⇒ every managed field is guarded, a create-only one included. An update-managed
field is stamped by the server on every write; a
applyOn: ["create"]field is stamped at birth and inert on update (the generated apply function offers no UPDATE SET candidate for it). Neither is ever a settable update key, so both are flagged, stripped, and omitted rather than left for consumer RLS to neutralise. - delete ⇒ none. A delete carries no payload, so nothing can be owned.
“Guarded” is NOT “stamped”: stamping is operation-scoped (applyOn.includes(operation)) and decides
what the applier writes; guarding decides what a client may not send. They coincide on create and
deliberately diverge on update.
The consuming surfaces, all of which must go through this predicate:
- the write route’s
getGuardedManagedFields(packages/server/src/mutations/route.ts) — the 400 violation check, the sanitizer, and the create/update validation schemas; - the client’s
stripManagedFields(packages/client/src/mutation.ts) — the outgoing-payload strip; - the apply-function generator’s
buildTableBranch(packages/server/src/mutations/plpgsql-apply.ts) — the INSERT/UPDATE candidate-column exclusions; - ManagedFieldColumnKeys /
ManagedFieldColumnKeysForOperation— the type-level twin behind SyncTableCreateInput / SyncTableUpdateInput.
Parameters
Section titled “Parameters”applyOn
Section titled “applyOn”readonly ManagedFieldApplyOn[]
operation
Section titled “operation”"create" | "update" | "delete"
Returns
Section titled “Returns”boolean