Vitest False Positive in PR Added in-memory locks for the process, fix for Bug #2579 temporary measure. #3060 #3073

Activity

1. davidw-philips

   added

   bugSomething isn't workingSomething isn't working

   on Nov 26, 2025
2. sstklen commented on Feb 25, 2026

   

   sstklen

   on Feb 25, 2026

   More actions

   Hey! I ran into a similar pattern in our bug knowledge base and thought this might help.

   What's happening: Vitest's global unhandled rejection handler captures the Promise rejection before .rejects.toThrow() can assert on it. This happens because the async function throws synchronously inside the Promise executor, and Vitest's error tracking hooks see the rejection before the test framework's .rejects wrapper can intercept it. The in-memory lock PR (#3060) added a test that calls a method expected to throw for a non-existent entity, but the thrown error propagates to Node's unhandledRejection event before Vitest's .rejects.toThrow() matcher resolves.

   What worked for us:

   Wrap the expected-to-throw call in a try/catch block inside the test instead of relying on .rejects.toThrow(), or use expect(async () => { await call(); }).rejects.toThrow() with an explicit await on the outer expect. Alternatively, if the method under test throws synchronously (not returning a rejected Promise), use expect(() => call()).toThrow() without .rejects. Another approach is to add a Vitest config option to suppress unhandled rejection warnings for known test patterns.

   Steps:

   1. Identify the failing test in the memory server test file (likely src/memory/tests or similar path) that uses .rejects.toThrow() for the 'non-existent entity' case
   2. Option A: Change from expect(promise).rejects.toThrow() to await expect(async () => { await methodCall(); }).rejects.toThrow('Entity does not exist') — ensuring the outer expect is properly awaited
   3. Option B: Wrap in try/catch: try { await methodCall(); expect.unreachable(); } catch (e) { expect(e.message).toBe('Entity does not exist'); }
   4. Option C: If the function throws synchronously before returning a Promise, use expect(() => methodCall()).toThrow() without .rejects
   5. Verify CI passes by running pnpm test:memory locally and confirming no 'Unhandled Errors' warning appears

   // Before (causes Vitest false positive unhandled rejection):
   it('should throw error for non-existent entity', async () => {
     await expect(server.getEntity('nonexistent')).rejects.toThrow('Entity does not exist');
   });
   
   // After (Option A - properly awaited async closure):
   it('should throw error for non-existent entity', async () => {
     await expect(async () => {
       await server.getEntity('nonexistent');
     }).rejects.toThrow('Entity does not exist');
   });
   
   // After (Option B - try/catch, most reliable):
   it('should throw error for non-existent entity', async () => {
     try {
       await server.getEntity('nonexistent');
       expect.unreachable('Should have thrown');
     } catch (e) {
       expect((e as Error).message).toBe('Entity does not exist');
     }
   });
   

   📊 We found 1 similar case in our knowledge base with the same pattern — this gives us medium confidence in this analysis.

   Hope this helps! Let me know if it doesn't match your case — happy to dig deeper. 🦞

   Disclosure: This analysis is from Confucius Debug, an AI-powered community KB for agent bugs. Please verify before applying.

   ---

   _{🦞 Confucius Debug — community knowledge base for AI agent bugs. Free to search via MCP.}
3. JosephDoUrden

   added a commit that references this issue on Apr 10, 2026

   fix(memory): resolve Vitest false positive for expected rejection

   ...

   This issue will close once commit fd782a8 is merged into the 'main' branch.

   fd782a8
4. olaservo

   closed this as completedin #3893on Sep 2, 2026
5. pull

   added a commit that references this issue on Sep 2, 2026

   fix(memory): resolve Vitest false positive for expected rejection (mo…

   ...

   This issue will close once commit cce08de is merged into the 'main' branch.

   cce08de
6. olaservo commented on Sep 2, 2026

   

   olaservo

   on Sep 2, 2026

   Member

   More actions

   Fixed by #3893, which wraps the assertion in an async closure so the expected rejection is scoped to the expect chain. Closing.