Flaky CI Failure: node-sdk DeviceSync — TypeError: Cannot read properties of undefined (reading 'messages')

[github-actions]

Flaky CI Failure: node-sdk DeviceSync — TypeError: Cannot read properties of undefined (reading 'messages')

Workflow: Test
Failed run: https://github.com/xmtp/libxmtp/actions/runs/29943331512
Commit: 3e10d5d
Failed jobs: test-node-sdk / Test (node-sdk) shard 1

Summary

One of the three DeviceSync tests in sdks/js/node-sdk/test/DeviceSync.test.ts failed with a TypeError: Cannot read properties of undefined (reading 'messages'). The test ran for ~14.5 seconds before failing, consistent with a timing/race condition. All 182 other tests in shard 1 passed.

Error Details

❯ test/DeviceSync.test.ts (3 tests | 1 failed)  14525ms
TypeError: Cannot read properties of undefined (reading 'messages')

 Test Files  1 failed | 14 passed (15)
       Tests  1 failed | 182 passed (183)

##[error]TypeError: Cannot read properties of undefined (reading 'messages')
error: recipe `test-node-sdk-ci` failed on line 37 with exit code 1

Analysis

The test file has three tests that call .messages() on conversation objects retrieved via getConversationById. The error means one of those calls was made on undefined — the lookup returned undefined rather than a valid conversation object. This is likely a race condition where the group isn't yet visible/synced on the second installation at assertion time.

The relevant patterns in the test file (lines 132, 151, 208):

const messagesBefore = await group2Before!.messages();  // line 132
const messagesAfter = await group2After!.messages();    // line 151
const messagesOnClient2 = await group2!.messages();     // line 208

The tests use expect(group2).not.toBeNull() as a guard, but getConversationById can return undefined (not null) if the sync hasn't completed, and not.toBeNull() does not catch undefined. The ! non-null assertion operator only satisfies TypeScript at compile time — at runtime it does nothing, so the .messages() call throws.

This is a test/code failure (not an infrastructure failure). The fix likely involves either using not.toBeNullOrUndefined() / not.toBeFalsy() as the guard, or adding more robust wait/retry logic before expecting the conversation to be visible on the second installation.

---

Reported by Flaky Failure Watcher

[github-actions]

Recurrence — 2026-07-24

Failed run: https://github.com/xmtp/libxmtp/actions/runs/30061129583
Commit: 53bc30e

What is new or different about this occurrence:

• Both shards failed (shard 1 and shard 2), not just one. Both ran the same test and hit the same error.
• Different error message: Previously TypeError: Cannot read properties of undefined (reading 'messages'). This time AssertionError: expected undefined to be truthy at test/DeviceSync.test.ts:222. This suggests a fix was applied (adding expect(c).toBeTruthy() guard at line 222 before calling .messages()), but the underlying race condition persists — getConversationById still returns undefined.
• Much longer test duration: ~90 seconds vs ~14.5 seconds previously. The test appears to have a 90-second timeout, suggesting either a retry/wait loop was added, or the test now waits longer before failing.
• Additional log evidence in shard 2: [GroupError::MissingSequenceId] SequenceId not found in local db — suggests the sync failure has a backend/DB component, not just a timing issue in the JS test.

The relevant failing code context:

220|       await client2.conversations.syncAll();
221|       const c = await client2.conversations.getConversationById(group.…
222|       expect(c).toBeTruthy();

Root cause is unchanged: syncAll() does not guarantee the conversation is visible via getConversationById immediately after, likely due to a race in MissingSequenceId resolution.