fix: reconcile after human message sends

[miyaontherelay]

Summary

Follow-up to PR #86. PR #86 added bounded channel/DM reconciliation for missed broker events, but a continuously focused Pear window can still miss inbound messages while the user keeps typing because focus, visibility, online, and broker-status triggers do not fire.

This PR adds a post-send reconciliation trigger by tracking optimistic human sends in the renderer store and scheduling human-message-sent reconciliation from useMessageReconciliation. It does not add IPC and does not touch ComposeBar.

Non-vacuity

Removing the new lastHumanMessageSentAt hook effect makes the new hook wiring test go RED. The test also verifies the store timestamp advances when addHumanMessage performs the optimistic insert.

Validation

• npx vitest run src/renderer/src/hooks/use-message-reconciliation.test.ts
• npx vitest run src/main/broker.test.ts src/renderer/src/hooks/use-message-reconciliation.test.ts
• npm test
• npm run build
• git diff --check HEAD~1..HEAD

[codeant-ai]

CodeAnt AI is reviewing your PR.

[coderabbitai]

Warning

Review limit reached

@miyaontherelay, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 4 minutes and 54 seconds. Learn how PR review limits work.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Free

Run ID: 501f27ff-6394-4a45-be6e-a56dfc8f9fb7

📥 Commits

Reviewing files that changed from the base of the PR and between 182d463 and be68769.

📒 Files selected for processing (3)

• src/renderer/src/hooks/use-message-reconciliation.test.ts
• src/renderer/src/hooks/use-message-reconciliation.ts
• src/renderer/src/stores/agent-store.ts

---

Note

🎁 Summarized by CodeRabbit Free

Your organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Pro by visiting https://app.coderabbit.ai/login.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Code Review

This pull request introduces tracking for human message send timestamps (lastHumanMessageSentAt) in the agent store and schedules message reconciliation when a human message is sent. It also adds corresponding unit tests. A review comment points out that asserting on the stringified source code of a React hook in the tests is brittle and recommends testing the hook's behavior instead.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Asserting on the stringified source code of a React hook (hooks.useMessageReconciliation.toString()) is highly brittle and considered an anti-pattern. This test will easily break if:

1. The code is minified or bundled (where variable names like s are mangled).
2. Code formatting changes (e.g., spacing, line breaks, or running Prettier).
3. Internal variables or selectors are refactored (e.g., renaming s to state).

Instead, you should test the hook's behavior. If @testing-library/react is available, you can use renderHook to verify that updating lastHumanMessageSentAt in the store triggers the reconciler's schedule function.

[miyaontherelay]

Review of #88 — Reconcile after human message sends

Verdict: APPROVE ✅

Tight, focused split-out of the R5 post-send trigger from PR #86. Diff is small (+60/-2, 3 files), wiring is clean, non-vacuity holds.

What it does

Closes the "continuous typing in a focused window misses inbound messages" gap. PR #86's reconciliation triggers (focus/visibility/online/broker-status/event-stream-diagnostic) don't fire when the user is sitting in a focused Pear window typing message after message. With a half-open WS, inbound messages keep getting dropped. This PR adds a human-message-sent trigger so each send schedules a reconciliation that catches up any missed inbound events.

Verification

Locally on the PR branch (fix/pear-post-send-reconciliation, HEAD be687696c6):

• npx vitest run src/renderer/src/hooks/use-message-reconciliation.test.ts → 10/10 pass.
• Non-vacuity confirmed: removed lastHumanMessageSentAt: timestamp from agent-store.ts addHumanMessage → tracks optimistic human sends for reconciliation triggers test FAILED (expected 1717000123000 to be 0). The wiring is genuinely tested.

Code quality

Clean wiring

• lastHumanMessageSentAt: timestamp is set in the same set() call as the optimistic insert (agent-store.ts:1004-1009) — single state update, no race between the insert and the trigger.
• clearAll() resets it to 0 — symmetric with initial state.
• The exported scheduleHumanMessageSentReconciliation helper is a pure function: testable in isolation without React. Guards > 0 to prevent firing on init.
• New useEffect is correctly dep'd on [lastHumanMessageSentAt, reconciler]. Debounce + in-flight + pendingRerun (from R4) handles burst sends naturally — typing 5 messages in 5s collapses to at most a couple of fetches.

Edge cases I checked

• Duplicate echo path: when isDuplicateHumanEcho returns true, the optimistic insert is skipped but lastHumanMessageSentAt still updates → still schedules. That's intentional and correct: the user pressed send, so triggering reconciliation is appropriate regardless of whether the local echo de-duped.
• Same-millisecond consecutive sends: if two sends happen in the same Date.now() ms, the second won't trigger the useEffect (value didn't change). Theoretical issue, but the 750ms debounce in createMessageReconciler would have collapsed them anyway. Not a real concern.
• Reset on clearAll: lastHumanMessageSentAt goes from N → 0. Helper guard (> 0) prevents a spurious schedule on clear. ✓

Test 3 (wires human message sends into the reconciliation hook) is a source-string match

The third new test inspects useMessageReconciliation.toString() and string-matches on s.lastHumanMessageSentAt, the helper call, and the dep array. That's brittle (a benign rename would break it), but it's a pragmatic way to verify integration without spinning up a full React renderer. Without something like it, someone could accidentally remove the wiring with the other tests still passing. I'd lean toward keeping it — the brittleness is worth the integration safety net here.

CI

• checks (ubuntu): SUCCESS
• CodeRabbit: SUCCESS
• packaged-mcp-smoke: still running on macos-latest at review time. Diff doesn't touch any MCP/packaging code, so this should pass cleanly. Will merge once it lands green.

What I'd ask for

Nothing. Ship it.