Summary

• getEventRawContentByIds and hydrateExecutionEvents (apps/server/src/services/crm/events.ts) resolved a meeting's S3 object by enumerating the querying user's own connection IDs and guessing ${connectionId}/${meetingId}.json for each , a guess that only works when the meeting was ingested under a connection the querying user actually owns.
• This breaks whenever a meeting is ingested under one user's connection but linked into a different user's deal conversation, which happens routinely for SDR-dialer (Orum) calls linked into an AE's pipeline. Confirmed against real Warp org data: a Gong-recorded Orum call made by rep Manveer, linked into a different rep's (Kendall's) "GeoTek" deal, read as "not found" even though the transcript genuinely exists in S3 under Manveer's connection.
• crm_meeting_events.transcription_key already holds the exact key set at ingestion time (storeMeetingInS3 writes ${ingestingConnectionId}/${meetingId}.json), but the SELECT in getEventRawContentByIds never read it, so the code had no choice but to guess.
• Added getMeetingFromS3ByKey (apps/server/src/pipelines.ts) and a shared resolveMeetingS3Object helper (apps/server/src/services/crm/events.ts) that try the recorded key directly first, falling back to the connection-ID-guessing loop (findMeetingInS3) only when no key is on record , this preserves correctness for older rows from before the column was reliably populated.
• Both call sites (getEventRawContentByIds's meeting branch and hydrateExecutionEvents's meeting branch) now use the shared resolver and log which path resolved the object (direct-key vs guessed-connection) via createStructuredLog, so a regression of this exact bug shows up in structured logs instead of requiring raw SQL forensics to catch.
• Narrowed findMeetingInS3/getMeetingFromS3ByKey/resolveMeetingS3Object to a new MeetingsBucketEnv type (Pick<CedarRuntimeEnv, 'MEETINGS_BUCKET' | 'MEETINGS_BUCKET_FALLBACK'>) instead of the full runtime env, since that's all they touch , this also makes them cleanly unit-testable with an in-memory bucket instead of a full env fake.

No real customer data was touched , the Warp/Kendall/Manveer case is diagnostic only; the code fix alone makes future reads of that row resolve correctly.

Test plan

• New regression test apps/server/src/services/crm/__tests__/meeting-s3-cross-user-resolution.test.ts pins the exact cross-user scenario with synthetic ids: a transcriptionKey set to otherUsersConnectionId/meetingId.json, the querying user's own connection IDs excluding that connection, and an S3 mock populated only at the transcriptionKey path , asserts the transcript is still retrieved via direct-key. Also covers: guess-only would have failed (sanity check on the fixture), fallback-to-guessing still works when no key is recorded, and a clean null when neither path resolves.
• pnpm --filter @zero/server exec vitest run src/services/crm/__tests__/meeting-s3-cross-user-resolution.test.ts , 4/4 passed
• Full related-suite regression run (12 files, 119 tests) covering other consumers of findMeetingInS3/conversation hydration , all passed
• pnpm --filter @zero/server run types , clean
• eslint on touched files , clean

🤖 Generated with Claude Code

https://claude.ai/code/session_01YZB5RgfxHLmuKtWof2wP4g

Greptile Summary

This PR adds authoritative meeting-transcript lookup by the recorded S3 key, retains connection-ID guessing for legacy rows, wires the resolver into raw-content and execution hydration, and adds focused resolver tests and structured resolution logging. The recorded-key approach fixes legitimate cross-user conversation reads, but using a client-writable key directly introduces an object-level authorization gap.

• Adds getMeetingFromS3ByKey with primary/fallback bucket support.
• Adds a shared resolver that reports direct