Reject invalid automation executions before persistence - #2454
Open
ymichael wants to merge 1 commit into
Open
Conversation
CLI callers can construct invalid runtime values despite TypeScript types. Parse with the persisted schema at the serialization seam so rejected create and update operations cannot commit poison rows.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Human comments
What was wrong
The automation CLI constructs create and update requests in-process, so TypeScript types were the only protection before the shared data writer serialized an execution. A runtime-invalid value such as an empty prompt was committed first; only the response/stored-row decoder then rejected it. That poisoned project listing and made an ordinary repair update decode and fail on the invalid row before it could write. This is the residual write-before-validation invariant behind #2166 after #2431 correctly removed the arbitrary prompt-length cap.
What changed
The shared execution serializer now parses the final execution with the existing persisted-row schema before converting it to JSON and issuing SQL. Both production writers use that seam, so CLI create, full replacement, and partial agent updates cannot persist an execution that later reads would reject. The stored schema remains unbounded for prompt length, preserving valid long prompts and recovery of older over-cap rows.
Focused server-harness regressions prove that rejected create leaves the project list empty and rejected full/partial updates preserve their previously valid rows. There is no server/daemon wire change, no
HOST_DAEMON_PROTOCOL_VERSIONbump, and no CLI/guide/doc surface change; the same invalid input still fails, now before persistence.How you verified
pnpm exec turbo run test typecheck build lint --filter=bb-plugin-automations --force(5 test files, 69 tests passed; all 6 Turbo tasks succeeded, including long-prompt and scheduler coverage)pnpm exec oxfmt plugins/automations/src/data.ts plugins/automations/src/server-harness.test.ts --checkpnpm exec oxlint plugins/automations/src/data.ts plugins/automations/src/server-harness.test.tsgit diff --check 1f064e5a0b11d0a1e84b5fe6b3600ffc66ad9445Fixes #2166