Conversation
Bug Report
Comments? Email us. |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. Warning Rate limit exceeded@MrgSub has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 1 minutes and 50 seconds before requesting another review. ⌛ 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. 📒 Files selected for processing (7)
WalkthroughThis update introduces a new Durable Object, Changes
Sequence Diagram(s)sequenceDiagram
participant Client
participant ZeroDriver
participant ThreadSyncWorker
participant KVStore
Client->>ZeroDriver: syncThreads(folder)
ZeroDriver->>ThreadSyncWorker: syncThread(connection, threadId)
ThreadSyncWorker->>KVStore: Store thread data (connectionId:threadId)
ThreadSyncWorker-->>ZeroDriver: Return parsed message
ZeroDriver-->>Client: Return sync result
Estimated code review effort🎯 4 (Complex) | ⏱️ ~40 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
✨ Finishing Touches
🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (7)
apps/mail/components/mail/mail.tsx(1 hunks)apps/server/src/env.ts(2 hunks)apps/server/src/lib/gmail-rate-limit.ts(1 hunks)apps/server/src/main.ts(2 hunks)apps/server/src/routes/agent/index.ts(11 hunks)apps/server/src/routes/agent/sync-worker.ts(1 hunks)apps/server/wrangler.jsonc(6 hunks)
🧰 Additional context used
📓 Path-based instructions (4)
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit Inference Engine (AGENT.md)
**/*.{js,jsx,ts,tsx}: Use 2-space indentation
Use single quotes for strings
Limit lines to 100 characters in length
Semicolons are required at the end of statements
Files:
apps/server/src/env.tsapps/server/src/routes/agent/sync-worker.tsapps/server/src/main.tsapps/mail/components/mail/mail.tsxapps/server/src/lib/gmail-rate-limit.tsapps/server/src/routes/agent/index.ts
**/*.{js,jsx,ts,tsx,css,scss}
📄 CodeRabbit Inference Engine (AGENT.md)
Use Prettier with sort-imports and Tailwind plugins for code formatting
Files:
apps/server/src/env.tsapps/server/src/routes/agent/sync-worker.tsapps/server/src/main.tsapps/mail/components/mail/mail.tsxapps/server/src/lib/gmail-rate-limit.tsapps/server/src/routes/agent/index.ts
**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (AGENT.md)
Enable TypeScript strict mode
Files:
apps/server/src/env.tsapps/server/src/routes/agent/sync-worker.tsapps/server/src/main.tsapps/mail/components/mail/mail.tsxapps/server/src/lib/gmail-rate-limit.tsapps/server/src/routes/agent/index.ts
**/*.{css,js,ts,jsx,tsx,mdx}
📄 CodeRabbit Inference Engine (.cursor/rules/tailwind-css-v4.mdc)
**/*.{css,js,ts,jsx,tsx,mdx}: Chain variants together for composable variants (e.g.,group-has-data-potato:opacity-100).
Use new variants such asstarting,not-*,inert,nth-*,in-*,open(for:popover-open), and**for all descendants.
Do not use deprecated utilities likebg-opacity-*,text-opacity-*,border-opacity-*, anddivide-opacity-*; use the new syntax (e.g.,bg-black/50).
Use renamed utilities:shadow-smis nowshadow-xs,shadowis nowshadow-sm,drop-shadow-smis nowdrop-shadow-xs,drop-shadowis nowdrop-shadow-sm,blur-smis nowblur-xs,bluris nowblur-sm,rounded-smis nowrounded-xs,roundedis nowrounded-sm,outline-noneis nowoutline-hidden.
Usebg-(--brand-color)syntax for CSS variables in arbitrary values instead ofbg-[--brand-color].
Stacked variants now apply left-to-right instead of right-to-left.
Files:
apps/server/src/env.tsapps/server/src/routes/agent/sync-worker.tsapps/server/src/main.tsapps/mail/components/mail/mail.tsxapps/server/src/lib/gmail-rate-limit.tsapps/server/src/routes/agent/index.ts
🧠 Learnings (7)
📓 Common learnings
Learnt from: retrogtx
PR: Mail-0/Zero#1328
File: apps/mail/lib/hotkeys/mail-list-hotkeys.tsx:202-209
Timestamp: 2025-06-18T17:26:50.918Z
Learning: In apps/mail/lib/hotkeys/mail-list-hotkeys.tsx, the switchCategoryByIndex function using hardcoded indices for category hotkeys does not break when users reorder categories, contrary to the theoretical index-shifting issue. The actual implementation has constraints or mechanisms that prevent hotkey targeting issues.
📚 Learning: in apps/server/src/trpc/routes/mail.ts, the attachment processing logic conditionally handles mixed ...
Learnt from: retrogtx
PR: Mail-0/Zero#1468
File: apps/server/src/trpc/routes/mail.ts:386-391
Timestamp: 2025-06-27T04:59:29.731Z
Learning: In apps/server/src/trpc/routes/mail.ts, the attachment processing logic conditionally handles mixed attachment types - it preserves existing File-like objects with arrayBuffer methods while only converting serialized attachments that need processing through toAttachmentFiles.
Applied to files:
apps/server/src/routes/agent/sync-worker.tsapps/server/src/main.tsapps/server/src/routes/agent/index.ts
📚 Learning: in apps/mail/lib/hotkeys/mail-list-hotkeys.tsx, the switchcategorybyindex function using hardcoded i...
Learnt from: retrogtx
PR: Mail-0/Zero#1328
File: apps/mail/lib/hotkeys/mail-list-hotkeys.tsx:202-209
Timestamp: 2025-06-18T17:26:50.918Z
Learning: In apps/mail/lib/hotkeys/mail-list-hotkeys.tsx, the switchCategoryByIndex function using hardcoded indices for category hotkeys does not break when users reorder categories, contrary to the theoretical index-shifting issue. The actual implementation has constraints or mechanisms that prevent hotkey targeting issues.
Applied to files:
apps/mail/components/mail/mail.tsx
📚 Learning: applies to **/*.{css,js,ts,jsx,tsx,mdx} : use renamed utilities: `shadow-sm` is now `shadow-xs`, `sh...
Learnt from: CR
PR: Mail-0/Zero#0
File: .cursor/rules/tailwind-css-v4.mdc:0-0
Timestamp: 2025-08-03T20:42:04.207Z
Learning: Applies to **/*.{css,js,ts,jsx,tsx,mdx} : Use renamed utilities: `shadow-sm` is now `shadow-xs`, `shadow` is now `shadow-sm`, `drop-shadow-sm` is now `drop-shadow-xs`, `drop-shadow` is now `drop-shadow-sm`, `blur-sm` is now `blur-xs`, `blur` is now `blur-sm`, `rounded-sm` is now `rounded-xs`, `rounded` is now `rounded-sm`, `outline-none` is now `outline-hidden`.
Applied to files:
apps/mail/components/mail/mail.tsx
📚 Learning: in apps/server/src/trpc/routes/mail.ts, the user indicated they are not using iso format for the sch...
Learnt from: retrogtx
PR: Mail-0/Zero#1468
File: apps/server/src/trpc/routes/mail.ts:331-331
Timestamp: 2025-06-28T03:56:09.376Z
Learning: In apps/server/src/trpc/routes/mail.ts, the user indicated they are not using ISO format for the scheduleAt parameter, despite the frontend code showing toISOString() usage in the ScheduleSendPicker component.
Applied to files:
apps/server/src/lib/gmail-rate-limit.ts
📚 Learning: in apps/server/src/lib/driver/google.ts, the normalization of "draft" to "drafts" in the count() met...
Learnt from: retrogtx
PR: Mail-0/Zero#1734
File: apps/server/src/lib/driver/google.ts:211-221
Timestamp: 2025-07-15T06:46:33.349Z
Learning: In apps/server/src/lib/driver/google.ts, the normalization of "draft" to "drafts" in the count() method is necessary because the navigation item in apps/mail/config/navigation.ts has id: 'drafts' (plural) while the Google API returns "draft" (singular). The nav-main.tsx component matches stats by comparing stat.label with item.id, so the backend must return "drafts" for the draft counter badge to appear in the sidebar.
Applied to files:
apps/server/src/lib/gmail-rate-limit.tsapps/server/src/routes/agent/index.ts
📚 Learning: run `pnpm db:push` after schema changes...
Learnt from: CR
PR: Mail-0/Zero#0
File: AGENT.md:0-0
Timestamp: 2025-08-03T20:41:43.899Z
Learning: Run `pnpm db:push` after schema changes
Applied to files:
apps/server/src/routes/agent/index.ts
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: cubic · AI code reviewer
- GitHub Check: Cursor Bugbot
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (12)
apps/mail/components/mail/mail.tsx (1)
20-20: Mars-level efficiency: hotkeys have been jettisoned.I see we've removed the numeric hotkeys for category filtering (1-9 keys plus 0 to clear). This is a significant UX change - users could previously quickly switch between categories using keyboard shortcuts. Want to make sure this removal is intentional and not an accidental side effect of the ThreadSyncWorker refactor.
Were these hotkeys causing issues, or is this part of a broader UI simplification strategy? The previous learning suggests these hotkeys were working correctly even with category reordering.
apps/server/src/main.ts (2)
25-25: Excellent integration of the new ThreadSyncWorker.Clean import addition that properly integrates the new Durable Object into our architecture. This is the kind of methodical engineering approach that gets us to production without explosions.
1061-1061: ThreadSyncWorker successfully added to the export constellation.Perfect addition to our export list. The ThreadSyncWorker is now ready to handle thread synchronization across the entire system. This modular approach is exactly what we need for scaling our email infrastructure to handle millions of users.
apps/server/src/env.ts (2)
1-1: Brilliant type integration, like adding another rocket to our fleet.Clean addition of ThreadSyncWorker to the import statement. This follows our established pattern and maintains type safety across the entire system.
13-13: ThreadSyncWorker namespace properly integrated into the environment.Perfect addition to the ZeroEnv type. The new Durable Object now has its proper place in our environment configuration, ready to handle thread synchronization at scale. This is the kind of systematic approach that prevents runtime surprises.
apps/server/wrangler.jsonc (6)
61-64: ThreadSyncWorker successfully configured for local environment.Excellent addition of the new Durable Object binding. The configuration is clean and follows our established patterns. This gives us the infrastructure foundation for our new thread synchronization architecture.
123-126: Local migration properly configured for v8.Perfect migration entry for the ThreadSyncWorker in local environment. The v8 tag is appropriate and the new_sqlite_classes configuration will ensure proper database setup.
257-260: Staging environment locked and loaded with ThreadSyncWorker.Clean configuration for staging environment. The binding follows the same pattern as local, ensuring consistency across our deployment pipeline.
329-332: Staging migration configured for v9 - proper version control.The v9 migration tag for staging makes sense given the different migration history between environments. This systematic approach prevents database schema conflicts.
464-467: Production ThreadSyncWorker ready for launch.Production environment properly configured with the ThreadSyncWorker binding. This completes our deployment pipeline setup - we're ready to handle thread synchronization at production scale.
530-533: Production migration configured for maximum reliability.The v9 migration tag aligns with staging, maintaining consistency between pre-production and production environments. This is the kind of careful configuration management that prevents 3 AM emergency calls.
apps/server/src/routes/agent/index.ts (1)
653-673: This sync logic is now limited to inbox only - is that intentional?The refactored
syncFoldersmethod now only syncs the inbox folder by callingsyncThreads()without parameters (which defaults to 'inbox'). Previously, this could sync multiple folders. If you need to sync other folders like sent, drafts, etc., this is a regression.Consider either:
- Keep it as-is if inbox-only sync is the new requirement
- Add logic to sync multiple folders if needed
| export const rateLimitSchedule = Schedule.recurWhile(isRateLimit) | ||
| .pipe(Schedule.intersect(Schedule.recurs(3))) // max 3 attempts | ||
| .pipe(Schedule.intersect(Schedule.recurs(10))) // max 3 attempts |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Update the comment to match reality, my friend.
The comment still says "max 3 attempts" but we're now doing 10 retries. This is like saying we're going to Mars but only packing lunch for the Moon. Let's make the documentation match the code so future engineers don't get confused about our retry strategy.
- .pipe(Schedule.intersect(Schedule.recurs(10))) // max 3 attempts
+ .pipe(Schedule.intersect(Schedule.recurs(10))) // max 10 attempts📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| export const rateLimitSchedule = Schedule.recurWhile(isRateLimit) | |
| .pipe(Schedule.intersect(Schedule.recurs(3))) // max 3 attempts | |
| .pipe(Schedule.intersect(Schedule.recurs(10))) // max 3 attempts | |
| export const rateLimitSchedule = Schedule.recurWhile(isRateLimit) | |
| .pipe(Schedule.intersect(Schedule.recurs(10))) // max 10 attempts |
🤖 Prompt for AI Agents
In apps/server/src/lib/gmail-rate-limit.ts around lines 35 to 36, the comment
incorrectly states "max 3 attempts" while the code actually sets the schedule to
recur every 10 units. Update the comment to accurately reflect that the schedule
allows for 10 retries instead of 3, ensuring the documentation matches the
current retry strategy.
| const latest = yield* Effect.tryPromise(() => | ||
| this.env.THREAD_SYNC_WORKER.get(this.env.THREAD_SYNC_WORKER.newUniqueId()).syncThread( | ||
| this.connection!, | ||
| threadId, | ||
| ), | ||
| Effect.catchAll((error) => { | ||
| console.error(`[syncThread] Failed to get thread data for ${threadId}:`, error); | ||
| return Effect.fail( | ||
| new ThreadDataError(`Failed to get thread data for ${threadId}`, error), | ||
| ); | ||
| }), | ||
| ); |
There was a problem hiding this comment.
Creating a new Durable Object instance for every sync is inefficient
You're creating a new unique Durable Object instance for each thread sync operation. This is wasteful and doesn't leverage the stateful nature of Durable Objects. You should reuse instances, perhaps one per connection.
Consider using a consistent ID strategy:
- this.env.THREAD_SYNC_WORKER.get(this.env.THREAD_SYNC_WORKER.newUniqueId()).syncThread(
+ this.env.THREAD_SYNC_WORKER.get(this.env.THREAD_SYNC_WORKER.idFromName(this.connection!.id)).syncThread(This would create one Durable Object per connection and reuse it for all thread syncs.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const latest = yield* Effect.tryPromise(() => | |
| this.env.THREAD_SYNC_WORKER.get(this.env.THREAD_SYNC_WORKER.newUniqueId()).syncThread( | |
| this.connection!, | |
| threadId, | |
| ), | |
| Effect.catchAll((error) => { | |
| console.error(`[syncThread] Failed to get thread data for ${threadId}:`, error); | |
| return Effect.fail( | |
| new ThreadDataError(`Failed to get thread data for ${threadId}`, error), | |
| ); | |
| }), | |
| ); | |
| const latest = yield* Effect.tryPromise(() => | |
| this.env.THREAD_SYNC_WORKER.get(this.env.THREAD_SYNC_WORKER.idFromName(this.connection!.id)).syncThread( | |
| this.connection!, | |
| threadId, | |
| ), | |
| ); |
🤖 Prompt for AI Agents
In apps/server/src/routes/agent/index.ts around lines 871 to 876, the code
creates a new unique Durable Object instance for every thread sync, which is
inefficient. Instead, implement a consistent ID strategy to reuse a single
Durable Object instance per connection. Modify the code to generate or retrieve
a Durable Object ID based on the connection, then use that ID to get the Durable
Object instance before calling syncThread, ensuring the same instance is reused
for all syncs on that connection.
| const syncEffects = threadIds.map(syncSingleThread); | ||
|
|
||
| yield* Effect.all(syncEffects, { concurrency: 1, discard: true }).pipe( | ||
| yield* Effect.all(syncEffects, { concurrency: 1 }).pipe( |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Concurrency is hardcoded to 1 - this could be a bottleneck
Setting concurrency to 1 means threads are synced sequentially. While this helps with rate limiting, it significantly slows down the sync process.
Consider making this configurable or using a higher value with proper rate limiting:
- yield* Effect.all(syncEffects, { concurrency: 1 }).pipe(
+ yield* Effect.all(syncEffects, { concurrency: this.env.SYNC_CONCURRENCY || 5 }).pipe(📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| yield* Effect.all(syncEffects, { concurrency: 1 }).pipe( | |
| yield* Effect.all(syncEffects, { concurrency: this.env.SYNC_CONCURRENCY || 5 }).pipe( |
🤖 Prompt for AI Agents
In apps/server/src/routes/agent/index.ts at line 1164, the concurrency for
Effect.all is hardcoded to 1, causing sequential execution and potential
performance bottlenecks. Modify the code to make the concurrency value
configurable via a parameter or environment variable, allowing it to be adjusted
as needed. Ensure that any increase in concurrency is accompanied by appropriate
rate limiting to prevent overload.
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
cubic analysis
3 issues found across 7 files • Review in cubic
React with 👍 or 👎 to teach cubic. You can also tag @cubic-dev-ai to give feedback, ask questions, or re-run the review.
| this.ctx.waitUntil(this.syncThreads('inbox')); | ||
| this.ctx.waitUntil(this.syncThreads('sent')); | ||
| this.ctx.waitUntil(this.syncThreads('spam')); | ||
| this.ctx.waitUntil(this.syncThreads()); |
There was a problem hiding this comment.
Only the inbox is synchronised; sent and spam folders are no longer queued, causing functional regression.
Prompt for AI agents
Address the following comment on apps/server/src/routes/agent/index.ts at line 667:
<comment>Only the inbox is synchronised; sent and spam folders are no longer queued, causing functional regression.</comment>
<file context>
@@ -660,9 +664,7 @@ export class ZeroDriver extends DurableObject<ZeroEnv> {
console.log(
`[syncFolders] Starting folder sync for ${this.name} (threadCount: ${threadCount})`,
);
- this.ctx.waitUntil(this.syncThreads('inbox'));
- this.ctx.waitUntil(this.syncThreads('sent'));
- this.ctx.waitUntil(this.syncThreads('spam'));
+ this.ctx.waitUntil(this.syncThreads());
} else {
console.log(
</file context>
| const decoder = new TextDecoder(); | ||
| const maxCount = 20; | ||
| const shouldLoop = env.THREAD_SYNC_LOOP !== 'false'; | ||
| const shouldLoop = true; |
There was a problem hiding this comment.
Loop-control flag is hard-coded, ignoring the THREAD_SYNC_LOOP environment variable and preventing operators from disabling continuous pagination.
Prompt for AI agents
Address the following comment on apps/server/src/routes/agent/index.ts at line 78:
<comment>Loop-control flag is hard-coded, ignoring the THREAD_SYNC_LOOP environment variable and preventing operators from disabling continuous pagination.</comment>
<file context>
@@ -75,7 +75,7 @@ import { eq } from 'drizzle-orm';
const decoder = new TextDecoder();
const maxCount = 20;
-const shouldLoop = env.THREAD_SYNC_LOOP !== 'false';
+const shouldLoop = true;
// Error types for getUserTopics
</file context>
| */ | ||
| export const rateLimitSchedule = Schedule.recurWhile(isRateLimit) | ||
| .pipe(Schedule.intersect(Schedule.recurs(3))) // max 3 attempts | ||
| .pipe(Schedule.intersect(Schedule.recurs(10))) // max 3 attempts |
There was a problem hiding this comment.
Inline comment contradicts the actual retry count (10), making the documentation misleading and likely to cause confusion. (Based on your team's feedback about keeping comments accurate to avoid maintenance errors.)
Prompt for AI agents
Address the following comment on apps/server/src/lib/gmail-rate-limit.ts at line 36:
<comment>Inline comment contradicts the actual retry count (10), making the documentation misleading and likely to cause confusion. (Based on your team's feedback about keeping comments accurate to avoid maintenance errors.)</comment>
<file context>
@@ -33,7 +33,7 @@ export function isRateLimit(err: unknown): boolean {
* – stops immediately for any other error
*/
export const rateLimitSchedule = Schedule.recurWhile(isRateLimit)
- .pipe(Schedule.intersect(Schedule.recurs(3))) // max 3 attempts
+ .pipe(Schedule.intersect(Schedule.recurs(10))) // max 3 attempts
.pipe(Schedule.addDelay(() => Duration.seconds(60))); // 60s delay between retries
</file context>
| .pipe(Schedule.intersect(Schedule.recurs(10))) // max 3 attempts | |
| .pipe(Schedule.intersect(Schedule.recurs(10))) // max 10 attempts |
MrgSub
force-pushed
the
ZEROAdd_ThreadSyncWorker_for_improved_thread_synchronization
branch
from
98afddc to
3bffaf2
Compare
Bug Report
Comments? Email us. |
Bug Report
Comments? Email us. |
MrgSub
force-pushed
the
ZEROAdd_ThreadSyncWorker_for_improved_thread_synchronization
branch
from
e9ef170 to
0afaeb9
Compare
|
An error occured. This error may be due to rate limits. If this error persists, please email us. |
MrgSub
deleted the
ZEROAdd_ThreadSyncWorker_for_improved_thread_synchronization
branch
🚨 Bugbot Trial ExpiredYour Bugbot trial has expired. Please purchase a license in the Cursor dashboard to continue using Bugbot. |
1 participant
READ CAREFULLY THEN REMOVE
Remove bullet points that are not relevant.
PLEASE REFRAIN FROM USING AI TO WRITE YOUR CODE AND PR DESCRIPTION. IF YOU DO USE AI TO WRITE YOUR CODE PLEASE PROVIDE A DESCRIPTION AND REVIEW IT CAREFULLY. MAKE SURE YOU UNDERSTAND THE CODE YOU ARE SUBMITTING USING AI.
Description
Please provide a clear description of your changes.
Type of Change
Please delete options that are not relevant.
Areas Affected
Please check all that apply:
Testing Done
Describe the tests you've done:
Security Considerations
For changes involving data or authentication:
Checklist
Additional Notes
Add any other context about the pull request here.
Screenshots/Recordings
Add screenshots or recordings here if applicable.
By submitting this pull request, I confirm that my contribution is made under the terms of the project's license.
Summary by cubic
Added a ThreadSyncWorker Durable Object to handle thread synchronization, improving reliability and separation of concerns in thread syncing.
Summary by CodeRabbit
New Features
Bug Fixes
Chores