Conversation
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 20 minutes and 12 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the 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 have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughIntroduces a Changes
Possibly related PRs
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
js/app/packages/block-pdf/component/TopBar.tsx (1)
87-87:⚠️ Potential issue | 🟠 MajorStale
fileTypeclosure — chat will often fail to attach for PDFs.
fileTypeis read once at line 87 during theTopBarcomponent's initial run. Solid components don't re-execute, so ifblockMetadataSignal()hasn't populated yet (common on first render before metadata loads),fileTypestaysundefinedfor the lifetime of this toolbar instance. The Chat action/ChatWithAgentButtonwill then callopenChatWithAgentwithfileType: undefined,asFileTypereturnsundefined,buildAttachmentreturnsundefined, and the user sees the "Can't attach this item to a chat" toast even though the PDF is perfectly valid.Read it reactively inside the closures instead.
🛠️ Proposed fix
- const fileType = blockMetadataSignal()?.fileType; + const fileType = () => blockMetadataSignal()?.fileType; @@ - action: () => - openChatWithAgent({ - type: 'document', - id: documentId, - name: fileName(), - fileType, - }), + action: () => + openChatWithAgent({ + type: 'document', + id: documentId, + name: fileName(), + fileType: fileType(), + }), divideAbove: true, buttonComponent: () => ( <ChatWithAgentButton entity={{ type: 'document', id: documentId, name: fileName(), - fileType, + fileType: fileType(), }} /> ),Also check the
fileType === 'docx'branch at line 192 — it has the same stale-closure problem for the "Download DOCX" menu item.Also applies to: 232-253
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@js/app/packages/block-pdf/component/TopBar.tsx` at line 87, The TopBar component currently captures fileType once into the const fileType = blockMetadataSignal()?.fileType causing stale-closure bugs; update closures (the Chat action/ChatWithAgentButton that calls openChatWithAgent, asFileType/buildAttachment usage) to call blockMetadataSignal()?.fileType (or read blockMetadataSignal() inside the handler) at invocation time instead of using the top-level fileType variable so the latest metadata is used; also fix the "Download DOCX" branch (the fileType === 'docx' conditional around the menu item) and the other affected closures (around lines referenced for 232-253) to evaluate fileType reactively inside their callbacks rather than relying on the captured fileType constant.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@js/app/packages/app/component/ChatWithAgentButton.tsx`:
- Around line 98-116: The ChatWithAgentButton duplicates markup and spacing with
the inline Task button — extract a small reusable primitive (e.g.,
AnimatedToolbarButton) that encapsulates the wrapper div + button classes, hover
handling and animated icon props (use it to render AnimatedStarIcon and call
openChatWithAgent(entity)); remove the hardcoded ml-1 from ChatWithAgentButton's
outer wrapper so spacing is controlled by parent toolbars, and replace the Task
button and ChatWithAgentButton to use the new AnimatedToolbarButton to avoid
drift.
- Around line 80-96: openChatWithAgent currently returns silently when
createChat() fails or returns no chatId; surface a user-facing toast and log the
error for debugging. Update openChatWithAgent so that after calling createChat()
you check for ('error' in result) or a missing result.chatId and then call
toast.failure with a concise message like "Unable to create chat" (including
brief error info if present), and also console.warn or processLogger the
result/error; keep early return after logging/toast. References:
openChatWithAgent, createChat, buildAttachment, storeChatStateImmediate,
globalSplitManager.
In `@js/app/packages/block-channel/component/NewChannelBlockAdapter.tsx`:
- Around line 109-129: The code calls toChatChannelType(channelType()) twice and
has a spacing conflict with ChatWithAgentButton's hardcoded ml-1; fix by
creating a single memo/accessor (e.g., const chatType =
toChatChannelType(channelType());) and use chatType() in the outer Show guard
and the inner Show/render body and pass chatType() into ChatWithAgentButton's
entity.channelType, and remove the redundant render-prop invocation; also remove
the hardcoded ml-1 on ChatWithAgentButton's outer div so spacing is governed by
the parent gap-1.5 (references: toChatChannelType, channelType,
ChatWithAgentButton, ChannelCallButton, ENABLE_CALLS).
In `@js/app/packages/block-email/component/TopBar.tsx`:
- Around line 187-204: The three related pieces—action, buttonComponent, and
condition—can diverge because action re-checks emailCtx.thread()?.db_id
independently; update action to assume condition was met and use the same
guarded value (thread id) or early-return consistently with condition, e.g.,
retrieve const threadId = emailCtx.thread()?.db_id once and if absent return,
then call openChatWithAgent({ type: 'email', id: threadId, name: props.title });
ensure this same guard pattern is mirrored in buttonComponent (which already
returns null when id is missing) so action, buttonComponent, and condition
remain consistent; reference: action, buttonComponent, condition,
emailCtx.thread()?.db_id, openChatWithAgent, ChatWithAgentButton, props.title.
---
Outside diff comments:
In `@js/app/packages/block-pdf/component/TopBar.tsx`:
- Line 87: The TopBar component currently captures fileType once into the const
fileType = blockMetadataSignal()?.fileType causing stale-closure bugs; update
closures (the Chat action/ChatWithAgentButton that calls openChatWithAgent,
asFileType/buildAttachment usage) to call blockMetadataSignal()?.fileType (or
read blockMetadataSignal() inside the handler) at invocation time instead of
using the top-level fileType variable so the latest metadata is used; also fix
the "Download DOCX" branch (the fileType === 'docx' conditional around the menu
item) and the other affected closures (around lines referenced for 232-253) to
evaluate fileType reactively inside their callbacks rather than relying on the
captured fileType constant.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 2c533add-5a9b-44b3-be1d-96d3b98fb940
⛔ Files ignored due to path filters (1)
js/bun.lockis excluded by!**/*.lock,!**/bun.lock
📒 Files selected for processing (7)
js/app/packages/app/component/ChatWithAgentButton.tsxjs/app/packages/block-channel/component/NewChannelBlockAdapter.tsxjs/app/packages/block-email/component/TopBar.tsxjs/app/packages/block-md/component/TopBar.tsxjs/app/packages/block-pdf/component/TopBar.tsxjs/app/packages/block-project/component/TopBar.tsxjs/app/packages/core/component/AI/util/storage.ts
- toast + warn when createChat() fails in openChatWithAgent - hoist toChatChannelType into a single accessor in NewTop Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1 participant
Summary
Adds a Chat button to block TopBars that creates a new chat with the current entity pre-attached and opens it in a new split.
Available on:
How it works
packages/app/component/ChatWithAgentButton.tsxexportsChatWithAgentButton,openChatWithAgent,ChatWithAgentIcon, andtoChatChannelType.openChatWithAgent(entity)builds the appropriateAttachment(email / document / project / channel), creates a chat viacreateChat(), seeds the attachment into the per-chat persisted state via the newstoreChatStateImmediatehelper in@core/component/AI/util/storage, and opens the chat in a new split.getChatInputStoredState(chatId)path — no changes needed inblock-chat.Notes
toChatChannelTypeto narrow@service-comms'sChannelTypeinto@service-cognition's equivalent at the boundary, avoiding cross-service casts.buildAttachmentcannot produce an attachment (e.g. unsupported document file type),openChatWithAgentshows a toast instead of silently no-oping.<Show>so no empty container renders when neither the chat button nor the call button is available.