Repository navigation
[codex] Add observer link and active chat reconciliation - #388
Conversation
|
Warning Review limit reached
Next review available in: 58 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces an observer link for workspace keys in the broker details page, implements periodic polling for visible active chat rooms, and adds deduplication logic to handle cases where a canonical message echo arrives before its optimistic counterpart. Feedback was provided regarding the deduplication window in isCanonicalAlreadyPresent; using the full 10-second window could cause subsequent identical messages to be incorrectly dropped, so a smaller 2-second window is recommended 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.
| function isCanonicalAlreadyPresent( | ||
| messages: ChatMessage[], | ||
| candidate: Pick<ChatMessage, 'body' | 'projectId' | 'timestamp' | 'to'> | ||
| ): boolean { | ||
| return messages.some((message) => message.local !== true && humanMessageContentMatches(message, candidate)) | ||
| } |
There was a problem hiding this comment.
Using humanMessageContentMatches inside isCanonicalAlreadyPresent applies the full 10-second HUMAN_MESSAGE_DEDUPE_WINDOW_MS deduplication window.\n\nIf a user sends an identical message (e.g., "ok", "yes", or "?") within 10 seconds of a previously confirmed message (where the canonical echo has already arrived and set local: false), the second message will be matched by isCanonicalAlreadyPresent and silently dropped.\n\nSince the inverse race (where the canonical echo beats the optimistic append) only occurs within a very tight window (typically milliseconds), we should use a much smaller window (e.g., 1–2 seconds) for isCanonicalAlreadyPresent to avoid dropping legitimate subsequent identical messages.
function isCanonicalAlreadyPresent(\n messages: ChatMessage[],\n candidate: Pick<ChatMessage, 'body' | 'projectId' | 'timestamp' | 'to'>\n): boolean {\n const REVERSE_RACE_WINDOW_MS = 2000\n return messages.some((message) =>\n message.local !== true &&\n isHumanMessage(message) &&\n message.body === candidate.body &&\n (!message.projectId || !candidate.projectId || message.projectId === candidate.projectId) &&\n normalizeMessageTarget(message.to) === normalizeMessageTarget(candidate.to) &&\n Math.abs(message.timestamp - candidate.timestamp) < REVERSE_RACE_WINDOW_MS\n )\n}There was a problem hiding this comment.
Addressed in 8bde2d6. I cherry-picked the follow-up dedupe fix onto this PR: the inverse-race guard now uses the tighter HUMAN_RACE_DEDUPE_WINDOW_MS, humanMessageContentMatches accepts a custom window, and isCanonicalAlreadyPresent only matches unclaimed canonical records (local === undefined) rather than reconciled history. Also added regression coverage for a repeated identical send after the first message has reconciled. Validated with npx vitest run src/renderer/src/stores/agent-store.test.ts src/renderer/src/stores/agent-store.stress.test.ts and npm run typecheck:web.
…ght window isCanonicalAlreadyPresent matched against any non-local record across the full 10s human dedupe window, including already-reconciled history (local: false) from an earlier send. That falsely suppressed the optimistic append of a later, legitimately repeated identical send. Scope the match to standalone, still-unclaimed canonical records (local === undefined) within a tight 2s race window — the guard exists to catch a sub-second startup race, not general dedupe. Addresses review feedback from gemini-code-assist, chatgpt-codex-connector, and coderabbitai on PR #387. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
# Conflicts: # src/renderer/src/hooks/use-message-reconciliation.test.ts
![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: 8bde2d6f41
ℹ️ 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".
|
|
||
| function observerUrlForWorkspaceKey(workspaceKey: string | undefined): string | undefined { | ||
| const key = workspaceKey?.trim() | ||
| return key ? `https://agentrelay.com/observer?key=${encodeURIComponent(key)}` : undefined |
There was a problem hiding this comment.
When Pear is running against a non-production cloud/relay deployment (RELAY_CLOUD_URL or a saved auth apiUrl; see src/main/auth.ts:getApiUrl), the workspace key belongs to that deployment, but this hard-coded production URL sends the Join flow and key to agentrelay.com, so observer joins either fail or use the wrong environment. Derive the observer origin from the configured cloud URL or include that URL in BrokerDetails before rendering the link.
Useful? React with 👍 / 👎.
1 participant
What changed
https://agentrelay.com/observer?key=....relay_inbound.Why
Messages sent by agents can be persisted and visible in the observer backend while Pear misses the live event path. The active room previously reconciled on tab/status/focus events, so a new backend-visible message could remain absent in Pear until another lifecycle event happened.
Validation
npx vitest run src/renderer/src/hooks/use-message-reconciliation.test.tsnpm run typecheck:web