You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Filed unassigned by the dev seat implementing #5934 (session session_013hfmP9hoMd3dJwTh85J4yB, branch claude/issue-5934-retire-onsuccess-callback, PR #7065). Observation, not a claim on anyone's time — the #5934 census measured this member too, so recording it saves the next reader the retake.
Duplicate-checked against all 266 open issues (repo-scoped REST listing, titles + bodies; /search/issues is unavailable at this seat; positive control: the same grep finds #5934 itself). No open card names onFailure.
What was measured (on 85b495795, during the #5934 census)
packages/core/src/actions/ActionRunner.ts declares, on the exported ActionDef of @object-ui/core:
onFailure?: ActionDef | ActionDef[];
read at the end of handlePostExecution and dispatched through executeChain when result.success is false.
Zero producers. The ActionRunner's legacy ActionDef.onSuccess chained-callback channel is unreachable from validated metadata and has zero producers #5934 writer census (286 onSuccess/onFailure-family hits classified by the "is the value an ActionDef written onto an action object" discriminator, with a positive control on chain) found exactly one writer of a callback-shaped onFailure: the runner's own pin ActionRunner.test.ts ("should execute onFailure callback after failure"). Everything else is React form callbacks on other surfaces, or @object-ui/types' separate Phase-2 ActionCallback declarations.
No spec counterpart, so no dual meaning. Unlike onSuccess, the pinned @objectstack/spec 17.2.0 declares NO onFailure key on ActionSchema — the key is not authorable at all, so validated metadata cannot reach the channel, and there is no declared meaning for it to converge on. It is a single-meaning, runner-native, unproduced channel on a published type.
The 2026-08-31 maintainer ruling on #5934 scoped the retirement to onSuccess alone, and PR #7065 explicitly leaves onFailure untouched (stated in the changeset and the ActionDef docblock). Removing onFailure would be its own breaking change to @object-ui/core — the human floor again — and the two obvious directions differ:
retire it like onSuccess (dead published surface, startup scope discipline), or
keep it as the one declared error-side hook until the spec grows an error-side key (it is the only post-failure extension point the runner has; the spec's onSuccess block deliberately has no failure twin).
Not asserting a verdict — triage question. The measurement exists; the member is documented as deliberately untouched at its declaration site.
Filed unassigned by the dev seat implementing #5934 (session
session_013hfmP9hoMd3dJwTh85J4yB, branchclaude/issue-5934-retire-onsuccess-callback, PR #7065). Observation, not a claim on anyone's time — the #5934 census measured this member too, so recording it saves the next reader the retake.Duplicate-checked against all 266 open issues (repo-scoped REST listing, titles + bodies;
/search/issuesis unavailable at this seat; positive control: the same grep finds #5934 itself). No open card namesonFailure.What was measured (on
85b495795, during the #5934 census)packages/core/src/actions/ActionRunner.tsdeclares, on the exportedActionDefof@object-ui/core:read at the end of
handlePostExecutionand dispatched throughexecuteChainwhenresult.successis false.ActionRunner's legacyActionDef.onSuccesschained-callback channel is unreachable from validated metadata and has zero producers #5934 writer census (286onSuccess/onFailure-family hits classified by the "is the value an ActionDef written onto an action object" discriminator, with a positive control onchain) found exactly one writer of a callback-shapedonFailure: the runner's own pinActionRunner.test.ts("should execute onFailure callback after failure"). Everything else is React form callbacks on other surfaces, or@object-ui/types' separate Phase-2ActionCallbackdeclarations.onSuccess, the pinned@objectstack/spec17.2.0 declares NOonFailurekey onActionSchema— the key is not authorable at all, so validated metadata cannot reach the channel, and there is no declared meaning for it to converge on. It is a single-meaning, runner-native, unproduced channel on a published type.Why record it rather than ride it into #5934
The 2026-08-31 maintainer ruling on #5934 scoped the retirement to
onSuccessalone, and PR #7065 explicitly leavesonFailureuntouched (stated in the changeset and theActionDefdocblock). RemovingonFailurewould be its own breaking change to@object-ui/core— the human floor again — and the two obvious directions differ:onSuccess(dead published surface, startup scope discipline), oronSuccessblock deliberately has no failure twin).Not asserting a verdict — triage question. The measurement exists; the member is documented as deliberately untouched at its declaration site.
Refs: #5934 · PR #7065