Skip to content

fix(console): protect agent creation inputs while submitting - #1378

Merged
swjnxyf merged 3 commits into
yyjeqhc:mainfrom
skygunner:contrib/audit-t5-agent-create-inputs
Nov 7, 2026
Merged

swjnxyf merged 3 commits into
yyjeqhc:mainfrom
skygunner:contrib/audit-t5-agent-create-inputs

Conversation

@skygunner

Copy link
Copy Markdown
Contributor

Problem

The create-Agent form kept its inputs enabled while the create request was in flight, and success unconditionally cleared every field. Text typed after submitting was therefore wiped by the success handler even though it was never part of the submitted Agent.

Reproduced with a controllable create response: submitting first-agent and typing unsaved-second-agent into the Handle field during the request lost the second input when the create succeeded — the user's unsaved draft was destroyed by the very completion they were waiting for.

Change

Disable the four create inputs for the duration of the create request and restore editing when it ends (the submit button already disabled on the hook-wide busy flag; it now also covers this request specifically). With inputs locked, success clears exactly what was submitted; failure and uncertain outcomes keep the operator's input for correction. The hook's existing idempotency snapshot and key-reuse behavior are unchanged, and no other part of the page is disabled.

Validation

  • New test in frontend/test-v2/agents-workbench.test.tsx: inputs lock while the create promise is pending, success clears the submitted fields and unlocks, and a failed creation keeps the typed handle and display name for correction (the lock path fails on the previous code).
  • npx vitest run (frontend): 43 files, 403 passed, 0 failed; npm run typecheck: clean.

Compatibility

None: one local component state, disabled attributes on four inputs, and one guard against double submission.

vincent and others added 3 commits November 7, 2026 03:55
The create-Agent form kept its inputs enabled while the create request was in
flight, and success unconditionally cleared every field. Text typed after
submitting was therefore wiped by the success handler even though it was never
part of the submitted Agent. Reproduced with a controllable create response:
submitting 'first-agent' and typing 'unsaved-second-agent' during the request
lost the second input on success.

Disable the four create inputs (and the submit button, which already covered
the busy flag) for the duration of the request and restore editing when it
ends. Success clears exactly what was submitted; failure and uncertain
outcomes keep the operator's input for correction. The hook's existing
idempotency snapshot and key-reuse behavior are unchanged.
# Conflicts:
#	frontend/test-v2/agents-workbench.test.tsx

@swjnxyf swjnxyf left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed create-Agent form field locking, success/reset and failure/draft preservation. Integrated current main including #1376's uncertain-operation notice tests (resolved overlapping test insertion without dropping either regression). Added a synchronous in-flight ref guard to block repeated same-batch submissions before React state commits. Regenerated checked-in frontend/dist/app.js in follow-up 9bf3869. On wkp, frontend typecheck and all 19 agent-workbench tests passed; git diff check clean. No remaining blocker; approving squash merge without waiting for intermediate CI.

@swjnxyf
swjnxyf merged commit d6188c4 into yyjeqhc:main Nov 7, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants