[console] Conditional required (requiredWhen): submit-time validation uses the mount-time snapshot — star correctly disappears, submit still blocked with zero POST

[baozhoutao]

Environment

@objectstack/*@17.0.0-rc.6, Console record create dialog.

Summary

The create form's submit-time required validation appears to be snapshotted when the dialog mounts. A requiredWhen predicate that later flips to FALSE updates the display layer (the required star disappears as expected) but not the validation layer: submit is still refused with " 不能为空", and no POST is issued at all.

Minimal repro (generic shape)

Object with a select field A (no defaultValue) and a lookup field B:

B: Field.lookup({
  requiredWhen: P`!(has(record.A) && record.A == "x")`,
})

1. Open the create dialog → B shows the required star (A key absent ⇒ predicate TRUE — expected).
2. Pick A = "x" → B's required star disappears (live re-evaluation works on the display layer).
3. Click Create → error "B 不能为空", and no POST /api/v1/data/<object> request is issued.
4. Control: open an edit dialog on an existing record whose A is already "x" → B unstared, save PATCHes 200. The only difference from step 3 is whether A had a value at mount time — which is what implicates a mount-time snapshot.

Assertions observed

• After step 2: B's label contains no *, no required marker in the field container.
• After step 3: inline error "B 不能为空" appears; network shows zero create POSTs.
• Server-side control (only the client is affected): direct POST /api/v1/data/<object> with {"A":"x"} and no B → 201; with A at another value and no B → 400 VALIDATION_FAILED. Server requiredWhen semantics are correct.

Expected

Submit-time validation should consume the same live resolveFieldRuleState result that drives the required star, not a snapshot taken at dialog mount.

Related (checked before filing — distinct issues)

• requiredWhen + a runtime defaultValue still deadlocks a create form (the conditional half of #4069) #4085 is the nearest neighbour but a different defect: there the predicate resolves TRUE on create and the deadlock comes from the producer-owned runtime defaultValue interplay. Here the predicate resolves FALSE by submit time and the block comes from the stale mount-time snapshot; no runtime default is involved (A deliberately has none).
• Possibly adjacent to PR fix(plugin-form): seed create forms from the object schema's declared defaults #4068 (create forms now seed from schema-declared defaults): seeding changes the mount-time record, hence the content of this snapshot. In this repro A has no default, so the snapshot is always "required".

Impact

Any "conditionally optional" field whose driving field has no defaultValue can never be left empty on a create form, even when the author's predicate says it may be. In the reporting app this pattern occurs 10+ times across objects.

[os-zhuang]

Triage: pm:queue — concrete defect with a minimal repro, a mount-time-vs-live control experiment (edit dialog with A="x" at mount saves fine; create dialog with A picked after mount blocks), and a server-side control proving the client is the failing layer (direct POST with the same shape → 201).

• Landing area on origin/main @ 521a37b: resolveFieldRuleState exists in packages/components/src/renderers/form/form.tsx and packages/core/src/evaluator/ — the body's expectation ("submit-time validation should consume the same live resolveFieldRuleState result that drives the star") names the right seam; the display layer demonstrably re-evaluates while the validation layer consumes a stale snapshot.
• Dup check: distinct from requiredWhen + a runtime defaultValue still deadlocks a create form (the conditional half of #4069) #4085 as the body itself establishes (there the predicate is TRUE on create and the deadlock involves a runtime defaultValue; here the predicate flips FALSE and no default exists — the block is the stale snapshot). PR fix(plugin-form): seed create forms from the object schema's declared defaults #4068 (schema-default seeding) is adjacency worth the dev reading, not a duplicate. No other open card covers submit-time requiredWhen staleness (local filter over cached open lists).

本评论来自分诊座位 Routine（#5474 试点），不构成认领。

---

Generated by Claude Code