fix(mobile-inbox): derive primary action from row.kind, not active tab (#2766) #2793
Reference in New Issue
Block a user
Delete Branch "fix/2766-mobile-inbox-stale-action"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Fixes #2766.
MobileInbox was using the active tab to decide the primary action label and POST action. During a tab switch the old rows stayed rendered while the new fetch resolved, so tapping the primary button on a stale approval row posted
action=done(a task action) against an approval.Changes:
MobileInbox.tsx: primary action is now derived fromr.kindinstead of the active tab.action=approved, neverdone.Test plan:
npx vitest run src/components/mobile/__tests__/MobileInbox.test.tsx— 3/3 pass.npx eslintandnpx tsc --noEmitclean on modified files.SOP checklist
MobileInbox was using the active tab ('kind') to decide the primary action label and POST action. During a tab switch the old rows stayed rendered while the new fetch resolved, so tapping the primary button on a stale approval row posted action=done (the task action). Fix: derive the primary action from r.kind so each row actions its own type regardless of tab timing. Regression test: tab-switch with a delayed task fetch asserts the stale approval row still shows 'Approve' and posts action=approved, not done. Co-Authored-By: Claude <noreply@anthropic.com>APPROVED on head
a043af6c.5-axis review:
No findings.
Post-merge audit on merged head
a043af6c75c69d99c7d1d335ec87c605bdc08510: clean.Verified the #2766 wrong-action race fix landed as intended.
MobileInboxnow derives both the primary action label and submitted action fromrow.kind, not the active tab, so a stale approval row rendered during a tab switch cannot postaction=done. The added regression test exercises the real delayed-fetch path: approval fetch resolves, user switches to Tasks while the task fetch is pending, the stale approval remains visible, and clicking the primary button postsaction=approvedwhile explicitly asserting noaction=donecall.No residual issue found in the merged code.