Repository navigation
fix(social): a friend Bot's held reply shows its approval card (overlay hook crash, in-chat match) (#254) - #256
Conversation
…ay hook crash, in-chat match) (ThinkFlowLab#254)
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: be4822d41b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| source: 'local', | ||
| from: composer ? 'You' : approval.senderName, | ||
| // The local Bot that wrote it (not a line you typed): its own chat shows the card (#254). | ||
| ...(!composer && typeof approval.request?.from === 'string' ? { fromId: approval.request.from } : {}), |
There was a problem hiding this comment.
When a local Bot Social send reaches failed (for example, approval succeeds but dispatch hits a network error), this newly admitted item is rendered as a fresh pending card: ChatApprovalDock.load() explicitly fetches failed approvals, but localHoldView() drops approval.status, so every offered action sends approve or reject, while approvals.decide() accepts only retry for a failed record. On the next poll the card therefore reappears and all of its controls reject as stale; preserve and handle the failed state (or leave failed entries to the global Retry card).
Useful? React with 👍 / 👎.
Fixes #254.
Root cause. Not a routing or #233/#239 regression. A's typed line reaches B's Helper as a request from the friend's Bot (shown as the person). Helper's reply is routed back by the host (
turns.js→replyRemote→bot.send, rolereply,auto-reply) and, by the owner design (Auto-send off), held for B's owner. B'sflybot/approvalsholds three of these (08:15, 11:00, 11:22 Asia/Shanghai). The card never showed, so nothing released them:FlyBotApprovals(global overlay) declared auseStateafter itsif (pending.length === 0) return null. First render has no holds, the next has one, and React throws "Rendered more hooks than during the previous render" (reproduced with React 18), so the overlay never drew. Since Approvals: approving a held send skips remaining middleware; approvals store gaps (PR #2 review) #12.ChatApprovalDockmatches a hold by the friend's handle or a room id.localHoldViewput the friend's handle object intoroomId, soapprovalsForOpenChatdropped it, and nothing matched the replying Bot's own chat.Fix. Hooks run on every render in the overlay (test with a stand-in renderer that enforces React's hook-count rule; fails without the fix).
localHoldViewkeepsroomIdto real room ids and exposes the writing Bot (fromId, not for lines you typed); the dock lists a local Bot's held reply in that Bot's own chat and in the friend's chat. No Bot Social server change.Left as designed. The reply stays held until the owner approves (or Auto-send is on for the pair). Owner question: should a reply to a line the friend typed themselves (attested) skip the hold? Not changed.
Docs: social invariant 8, core-client. Client rebuilt, patches regenerated.