-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Deploy to production (Automated) #1801
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Co-authored-by: cubic-dev-ai[bot] <191113872+cubic-dev-ai[bot]@users.noreply.github.com>
Bug Report
Comments? Email us. Your free trial ends in 7 days. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.
|
Important Review skippedBot user detected. To trigger a single review, invoke the You can disable this status message by setting the 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Join our Discord community for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
zero-server-production | f66ba03 | Jul 23 2025, 03:47 PM |
Deploying zero-staging with
|
| Latest commit: |
f66ba03
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://54ca3a8d.zero-staging-c02.pages.dev |
Graphite Automations"Deploy to Production Helper" took an action on this PR • (07/22/25)1 reviewer was added to this PR based on Rahul Mishra's automation. |
Bug Report
Comments? Email us. Your free trial ends in 6 days. |
## Description Improved workflow processing reliability and efficiency in the email processing pipeline. Key changes include: 1. Refactored batch processing to properly handle message acknowledgment 2. Implemented atomic locking mechanism to prevent race conditions in history processing 3. Optimized thread label modification with a new DB-first approach 4. Fixed processing order in the Zero workflow to ensure history ID is updated before processing 5. Added thread-level processing checks to avoid duplicate processing 6. Enabled workflows in the development environment ## Type of Change - [x] 🐛 Bug fix (non-breaking change which fixes an issue) - [x] ⚡ Performance improvement ## Areas Affected - [x] Email Integration (Gmail, IMAP, etc.) - [x] Data Storage/Management ## Testing Done - [x] Manual testing performed ## Security Considerations - [x] No sensitive data is exposed ## Checklist - [x] I have performed a self-review of my code - [x] My changes generate no new warnings ## Additional Notes The changes significantly improve the reliability of email processing by preventing race conditions and duplicate processing. The new atomic locking mechanism ensures that each history and thread is processed exactly once, while the DB-first approach to label modification reduces API calls to Gmail. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added the ability to modify thread labels by label names or directly in the database, providing more flexible label management options. * **Improvements** * Enhanced label modification methods to allow skipping synchronization for faster updates when needed. * Improved workflow processing reliability through atomic locking to prevent duplicate processing. * Unified workflow execution for better consistency and maintainability. * **Configuration** * Workflows are now enabled by default in the local environment. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
Bug Report
Comments? Email us. Your free trial ends in 6 days. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bug: Queue Acknowledgment Removal Causes Redelivery
The batch.ackAll() calls were removed from both subscribe-queue and thread-queue processing cases. This prevents queue messages from being acknowledged, leading to their indefinite redelivery and reprocessing, causing duplicate work and potential infinite loops. The original try-finally structure ensured messages were acknowledged even if processing failed.
apps/server/src/main.ts#L713-L753
Lines 713 to 753 in f66ba03
| console.log('batch', batch); | |
| await Promise.all( | |
| batch.messages.map(async (msg: Message<ISubscribeBatch>) => { | |
| const connectionId = msg.body.connectionId; | |
| const providerId = msg.body.providerId; | |
| try { | |
| await enableBrainFunction({ id: connectionId, providerId }); | |
| } catch (error) { | |
| console.error( | |
| `Failed to enable brain function for connection ${connectionId}:`, | |
| error, | |
| ); | |
| } | |
| }), | |
| ); | |
| console.log('[SUBSCRIBE_QUEUE] batch done'); | |
| return; | |
| } | |
| case batch.queue.startsWith('thread-queue'): { | |
| await Promise.all( | |
| batch.messages.map(async (msg: Message<IThreadBatch>) => { | |
| const providerId = msg.body.providerId; | |
| const historyId = msg.body.historyId; | |
| const subscriptionName = msg.body.subscriptionName; | |
| const workflow = runWorkflow(EWorkflowType.MAIN, { | |
| providerId, | |
| historyId, | |
| subscriptionName, | |
| }); | |
| try { | |
| const result = await Effect.runPromise(workflow); | |
| console.log('[THREAD_QUEUE] result', result); | |
| } catch (error) { | |
| console.error('Error running workflow', error); | |
| } | |
| }), | |
| ); | |
| break; | |
| } | |
| } |
Bug: Thread Processing Workflow Disabled
The threadsChanged set is always empty because the logic responsible for adding thread IDs to it (e.g., for new messages or label changes) has been commented out. As a result, the subsequent conditional check if (threadsChanged.size > 0) always evaluates to false, preventing the thread processing workflow from executing. This effectively disables workflow triggers for threads with new messages or label modifications.
apps/server/src/pipelines.effect.ts#L283-L302
Zero/apps/server/src/pipelines.effect.ts
Lines 283 to 302 in f66ba03
| if (messageAdded.message?.threadId) { | |
| // threadsChanged.add(messageAdded.message.threadId); | |
| threadsAdded.add(messageAdded.message.threadId); | |
| } | |
| }); | |
| } | |
| if (historyItem.labelsAdded) { | |
| historyItem.labelsAdded.forEach((labelAdded) => { | |
| if (labelAdded.message?.threadId) { | |
| // threadsChanged.add(labelAdded.message.threadId); | |
| } | |
| }); | |
| } | |
| if (historyItem.labelsRemoved) { | |
| historyItem.labelsRemoved.forEach((labelRemoved) => { | |
| if (labelRemoved.message?.threadId) { | |
| // threadsChanged.add(labelRemoved.message.threadId); | |
| } | |
| }); | |
| } |
Bugbot free trial expires on July 29, 2025
Learn more in the Cursor dashboard.
Was this report helpful? Give feedback by reacting with 👍 or 👎
|
/deploy |
This is an automated pull request to deploy the staging branch to production.
Please review the pull request and comment
/deployto merge this PR and deploy to production.Summary by cubic
Fixed a bug in the CLI welcome message to show a default username if the user environment variable is missing.