CI typecheck and every downstream E2E job is failing on main because of five pre-existing TypeScript errors — not from any one in-flight PR.
Reproduced just now on a clean checkout of origin/main (commit 6ad578ae) with npx tsc --noEmit -p packages/eve:
src/public/channels/chat-sdk/chatSdkChannel.ts(273,9): error TS2322
Type 'Thread<unknown, unknown>' is not assignable to
'string | SerializedThread | Thread<Record<string, unknown>, unknown>'.
src/public/channels/photon/inboundContent.test.ts(9,5): error TS2741
src/public/channels/photon/photonIMessageChannel.test.ts(45,7): error TS2741
src/public/channels/photon/photonIMessageChannel.test.ts(68,7): error TS2741
src/public/channels/photon/photonIMessageChannel.test.ts(90,7): error TS2741
Property 'fullName' is missing in type '{ isBot; isMe; userId; userName }'
but required in type 'Author'.
Probable cause
Recent chat-sdk dependency roll (vendored into .generated/compiled/chat/messages-BSoJG691.d.ts) added two requirements that existing callers don't yet satisfy:
Author gained a required fullName: string.MessageData gained required formatted: FormattedContent (an mdast Root), metadata: MessageMetadata, and attachments: Attachment[].
The photon tests only stub the old minimal Author; adding fullName alone surfaces the remaining formatted/metadata/attachments mismatches, so the repair is larger than a stub tweak. The chatSdkChannel error at line 273 is independent — event.thread is Thread<unknown, unknown> but bridgeSend expects Thread<Record<string, unknown>, unknown> (or string, or SerializedThread).
Impact
Every downstream E2E job (e2e-local, e2e-postgres, e2e-vercel on every agent scenario) fails at pnpm run build:js, which underlines the typecheck error. This blocks every open PR, including #1497 (Version Packages).
Suggested fix
From the outside it looks like a mechanical update pass on:
packages/eve/src/public/channels/chat-sdk/chatSdkChannel.ts:273 — narrow event.thread with a runtime guard or a generic constraint that matches bridgeSend.packages/eve/src/public/channels/photon/inboundContent.test.tspackages/eve/src/public/channels/photon/photonIMessageChannel.test.ts
— provide a richer Message fixture stub (fullName, formatted, metadata, attachments).
Happy to ship a small candidate repair if maintainers want contribution; flagging here first since these touch in-flight subsystems I don't own.
CI
typecheckand every downstream E2E job is failing onmainbecause of five pre-existing TypeScript errors — not from any one in-flight PR.Reproduced just now on a clean checkout of
origin/main(commit6ad578ae) withnpx tsc --noEmit -p packages/eve:Probable cause
Recent
chat-sdkdependency roll (vendored into.generated/compiled/chat/messages-BSoJG691.d.ts) added two requirements that existing callers don't yet satisfy:Authorgained a requiredfullName: string.MessageDatagained requiredformatted: FormattedContent(an mdastRoot),metadata: MessageMetadata, andattachments: Attachment[].The photon tests only stub the old minimal
Author; addingfullNamealone surfaces the remainingformatted/metadata/attachmentsmismatches, so the repair is larger than a stub tweak. The chatSdkChannel error at line 273 is independent —event.threadisThread<unknown, unknown>butbridgeSendexpectsThread<Record<string, unknown>, unknown>(orstring, orSerializedThread).Impact
Every downstream E2E job (
e2e-local,e2e-postgres,e2e-vercelon every agent scenario) fails atpnpm run build:js, which underlines the typecheck error. This blocks every open PR, including #1497 (Version Packages).Suggested fix
From the outside it looks like a mechanical update pass on:
packages/eve/src/public/channels/chat-sdk/chatSdkChannel.ts:273— narrowevent.threadwith a runtime guard or a generic constraint that matchesbridgeSend.packages/eve/src/public/channels/photon/inboundContent.test.tspackages/eve/src/public/channels/photon/photonIMessageChannel.test.ts— provide a richer
Messagefixture stub (fullName,formatted,metadata,attachments).Happy to ship a small candidate repair if maintainers want contribution; flagging here first since these touch in-flight subsystems I don't own.