fix(approvals): record-header Reject fires after one dialog again (#3126) - #3128
Open
baozhoutao wants to merge 1 commit into
Open
fix(approvals): record-header Reject fires after one dialog again (#3126)#3128baozhoutao wants to merge 1 commit into
baozhoutao wants to merge 1 commit into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
) Since #2961 made the record header's decision inputs live, Reject carried both `confirmText` and a collectable comment param. The ActionRunner chains confirm before param collection, so rejecting queued TWO dialogs — after "Continue" the request silently waited on a second, unexpected comment dialog, which downstream read as a dead button (zero requests, no toast). Drop `confirmText` from the Reject decision action: the param dialog is the confirmation surface, titled by the action and carrying the old confirm question (same `approvals.rejectConfirm` key) as its description. One decision, one dialog — matching Approve and the Approval Center. Verified end-to-end in a real Chromium harness: Reject → single dialog → Confirm → `reject_request` dispatched. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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.
Closes #3126.
根因(不是回调丢失)
#2961 把记录页头决策动作的死键
collectParams改成 runner 真读的actionParams之后,Reject 动作同时携带confirmText和 可收集的 comment 参数。ActionRunner的管线是先确认、后收参(ActionRunner.ts L517–541),于是驳回变成串联两个弹窗:POST …/reject按 rc.0 契约(确认即发请求)操作的用户和 e2e 在第 1 步就停了——第 2 个弹窗没人理,请求永远不发,表现为"零请求、无报错、无 toast 的静默哑火"。Approve 从未声明
confirmText(单弹窗),所以 issue 里"批准正常、驳回哑火、审批中心正常"三组对照全部吻合。已在真机 Chromium harness 全链路复现:修复前确认后确实弹出第二个弹窗、其「确认」后请求正常发出——dispatch 链路本身完好,坏的是交互契约。
修复
buildApprovalDecisionActions:Reject 不再声明confirmText;原确认文案(同一个approvals.rejectConfirmi18n key,各语言译文原样生效)改挂在description上,由参数弹窗展示。测试
confirmText(防双弹层回潮)+ 确认文案落在description。reject_request成功 dispatch,旧 alertdialog 不再出现。Changeset
@object-ui/app-shellpatch。🤖 Generated with Claude Code