packages/plugin-bootstrap/src/index.ts (3)

445-485: Critical: Race conditions in cancellation promise handling.

The cancelPromise implementation has multiple issues:

1. Clears the signal immediately after wait() resolves, preventing other cleanup code from accessing it
2. No error handling for memory creation or event emission failures
3. Missing validation that the cancellation content is appropriate for the context

   const cancelPromise = (async () => {
     const content = await cancelSignal.wait();
-    CancelRunSignal.clear(runId);
+    // Don't clear here - let the finally block handle it

     if (content) {
+      try {
         if (message.id) {
           content.inReplyTo = createUniqueUuid(runtime, message.id);
         }

         await callback(content);

         const cancelMemory = {
           id: asUUID(v4()),
           entityId: runtime.agentId,
           agentId: runtime.agentId,
           content,
           roomId: message.roomId,
           createdAt: Date.now(),
         };

         await runtime.createMemory(cancelMemory, 'messages');
         logger.debug('[Bootstrap] Saved cancel response to memory', {
           memoryId: cancelMemory.id,
         });
+      } catch (error) {
+        logger.error('[Bootstrap] Error handling cancellation:', error);
+        // Re-throw to ensure proper error propagation
+        throw error;
+      }
     }

     await runtime.emitEvent(EventType.RUN_ENDED, {
       runtime,
       runId,
       messageId: message.id,
       roomId: message.roomId,
       entityId: message.entityId,
       startTime,
       status: 'cancelled',
       endTime: Date.now(),
       duration: Date.now() - startTime,
       source: 'messageHandler',
     });
   })();

---

914-914: Race condition with Promise.race causing unhandled rejections.

The current Promise.race implementation allows the processing promise to continue running after cancellation, potentially causing duplicate RUN_ENDED events and unhandled promise rejections.

Consider using AbortController for proper cancellation:

+  const abortController = new AbortController();
+  
   const processingPromise = (async () => {
     try {
+      // Check abort signal periodically
+      if (abortController.signal.aborted) return;
+      
       // ... existing processing code ...
     } catch (error: any) {
+      if (abortController.signal.aborted) return;
       // ... existing error handling ...
     }
   })();

-  await Promise.race([processingPromise, timeoutPromise, cancelPromise]);
+  try {
+    const result = await Promise.race([processingPromise, timeoutPromise, cancelPromise]);
+    abortController.abort(); // Cancel any ongoing work
+    return result;
+  } finally {
+    abortController.abort(); // Ensure cleanup
+  }

---

351-382: Critical: Thread-safety and memory leak issues in CancelRunSignal.

The implementation has several concurrency and lifecycle issues:

1. Race condition: No synchronization when accessing the static byRunId Map from multiple concurrent requests
2. Memory leak: Signals may not be cleared if cancellation completes before the timeout promise
3. Double cleanup risk: Both cancelPromise and processingPromise call CancelRunSignal.clear(runId)

Consider these fixes:

 export class CancelRunSignal {
-  private static byRunId: Map<UUID, CancelRunSignal> = new Map();
+  private static readonly byRunId: Map<UUID, CancelRunSignal> = new Map();
+  private static readonly lock = new Map<UUID, Promise<void>>();
   private resolve?: (content?: Content) => void;
   private promise: Promise<Content | undefined>;
   public isCancelled = false;
+  private cleared = false;
+  
   constructor() {
     this.promise = new Promise<Content | undefined>((resolve) => {
       this.resolve = resolve;
     });
   }

   cancel(content?: Content) {
+    if (this.cleared) return;
     this.isCancelled = true;
     this.resolve?.(content);
   }

   wait() {
     return this.promise;
   }

-  static getSignal(runId: UUID) {
+  static async getSignal(runId: UUID) {
+    // Ensure thread-safe access
+    while (this.lock.has(runId)) {
+      await this.lock.get(runId);
+    }
+    
+    const lockPromise = Promise.resolve();
+    this.lock.set(runId, lockPromise);
+    
+    try {
       if (!this.byRunId.has(runId)) {
         this.byRunId.set(runId, new CancelRunSignal());
       }
       return this.byRunId.get(runId)!;
+    } finally {
+      this.lock.delete(runId);
+    }
   }

   static clear(runId: UUID) {
-    this.byRunId.delete(runId);
+    const signal = this.byRunId.get(runId);
+    if (signal && !signal.cleared) {
+      signal.cleared = true;
+      this.byRunId.delete(runId);
+    }
   }
 }

packages/test-utils/package.json (1)

4-4: Version bump OK.

Minor: zod is pinned to 3.24.2 here while other packages use ^3.24.4; consider harmonizing to avoid duplicate installs.

packages/plugin-bootstrap/src/index.ts (2)

547-550: Add more comprehensive cancellation checks.

The cancellation check after memory creation is good, but consider adding checks at other critical points to avoid unnecessary work.

   if (cancelSignal.isCancelled) {
     return;
   }

   const agentUserState = await runtime.getParticipantUserState(
     message.roomId,
     runtime.agentId
   );
+  
+  if (cancelSignal.isCancelled) {
+    return;
+  }

   // ... later in the code ...

   if (message.content.attachments && message.content.attachments.length > 0) {
+    if (cancelSignal.isCancelled) {
+      return;
+    }
     message.content.attachments = await processAttachments(
       message.content.attachments,
       runtime
     );

---

362-365: Consider adding cancellation reason tracking.

The cancel method accepts optional content but doesn't track the reason for cancellation, which could be useful for debugging and analytics.

+  public cancellationReason?: string;
+  
-  cancel(content?: Content) {
+  cancel(content?: Content, reason?: string) {
     this.isCancelled = true;
+    this.cancellationReason = reason;
     this.resolve?.(content);
   }

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: CR
PR: elizaOS/eliza#0
File: packages/project-starter/CLAUDE.md:0-0
Timestamp: 2025-07-28T23:42:53.140Z
Learning: Applies to packages/project-starter/**/package.json : Use `elizaos` CLI scripts in `package.json` for starting, developing, testing, and building the agent

Learnt from: CR
PR: elizaOS/eliza#0
File: packages/cli/src/utils/upgrade/CLAUDE.md:0-0
Timestamp: 2025-08-04T09:25:57.393Z
Learning: Applies to packages/cli/src/utils/upgrade/**/package.json : Update package.json to ensure the package name uses the elizaos-plugins/ prefix, dependencies are updated (especially elizaos/core), scripts are correct, and agentConfig section is present.

Learnt from: wtfsayo
PR: elizaOS/eliza#4493
File: packages/docs/docs/core/plugins.md:95-101
Timestamp: 2025-05-08T09:37:35.805Z
Learning: The ElizaOS CLI uses the plural form "plugins" for plugin management commands (e.g., "elizaos plugins add", "elizaos plugins remove", "elizaos plugins list"), while the singular form "plugin" is used for plugin development operations (e.g., "elizaos plugin publish").

Learnt from: CR
PR: elizaOS/eliza#0
File: .cursorrules:0-0
Timestamp: 2025-08-08T14:26:42.742Z
Learning: Import Pattern: Use elizaos/core in package code, packages/core in internal references

Learnt from: CR
PR: elizaOS/eliza#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-28T20:11:19.074Z
Learning: Applies to packages/!(core)/**/src/**/*.{ts,tsx} : In package code outside core, import elizaos/core (not 'packages/core')

Learnt from: standujar
PR: elizaOS/eliza#5848
File: packages/core/build.ts:142-146
Timestamp: 2025-08-30T13:49:37.549Z
Learning: In elizaos/core package, the root dist/index.d.ts file is automatically generated by tsc when running `tsc --project tsconfig.declarations.json` with multiple entry points (src/index.node.ts and src/index.browser.ts). This generates generic type definitions that work for all environments, and manually overwriting this file would break browser support.

Learnt from: wtfsayo
PR: elizaOS/eliza#0
File: :0-0
Timestamp: 2025-06-22T17:42:23.153Z
Learning: In the elizaOS/eliza repository, always use bun:test for testing instead of jest or vitest. Import testing utilities from 'bun:test' rather than 'jest/globals' or other testing frameworks.

Learnt from: yungalgo
PR: elizaOS/eliza#4813
File: packages/project-starter/package.json:9-9
Timestamp: 2025-05-28T16:15:33.419Z
Learning: Project starter packages like elizaos/project-starter are templates that users copy rather than install as dependencies, so minor path inconsistencies in package.json entry points are less critical than for published packages.

Learnt from: CR
PR: elizaOS/eliza#0
File: packages/project-starter/CLAUDE.md:0-0
Timestamp: 2025-07-28T23:42:53.140Z
Learning: Applies to packages/project-starter/src/plugin.ts : Define project-specific custom plugins in `src/plugin.ts` using the `Plugin` interface from `elizaos/core`

Learnt from: CR
PR: elizaOS/eliza#0
File: packages/cli/src/utils/upgrade/CLAUDE.md:0-0
Timestamp: 2025-08-04T09:25:57.393Z
Learning: Applies to packages/cli/src/utils/upgrade/**/{tsconfig.json,tsconfig.build.json,tsup.config.ts} : Create and configure TypeScript and build configuration files: tsconfig.json, tsconfig.build.json, and tsup.config.ts as required for ElizaOS 1.x.

Learnt from: CR
PR: elizaOS/eliza#0
File: CLAUDE.md:0-0
Timestamp: 2025-08-28T20:11:19.074Z
Learning: Applies to **/package.json : Use workspace:* for all elizaos/* dependencies; never hardcode internal package versions

Learnt from: CR
PR: elizaOS/eliza#0
File: AGENTS.md:0-0
Timestamp: 2025-09-17T22:22:35.096Z
Learning: Applies to packages/cli/** : packages/cli contains the elizaos CLI; CLI code should live here

Learnt from: CR
PR: elizaOS/eliza#0
File: packages/plugin-starter/CLAUDE.md:0-0
Timestamp: 2025-07-28T23:42:39.951Z
Learning: Applies to packages/plugin-starter/**/package.json : Use the provided package.json template as a basis for your plugin's package.json

Learnt from: CR
PR: elizaOS/eliza#0
File: packages/plugin-starter/CLAUDE.md:0-0
Timestamp: 2025-07-28T23:42:39.951Z
Learning: Applies to packages/plugin-starter/src/index.ts : The main plugin export must follow the specified pattern in src/index.ts, exporting a Plugin object with services, actions, and optional providers/evaluators