mirror of
https://github.com/CopilotKit/CopilotKit.git
synced 2026-09-14 16:26:20 +08:00
Benjamin Taylor
e1f88ebc12
Addresses review feedback that channel-host.mts is doing too much.
Two changes, both scoped to the starters:
1. Channel construction moves to a new `channels.mts` beside `agent.ts` —
name resolution, `createChannel`, and the `onMessage` handler. That is
also the file to edit to customise a Channel (commands, reactions,
onMention), which previously meant editing the host.
The per-framework agent import moves with it, so `channel-host.mts` is now
byte-identical in all 15 starters rather than 13 + 2.
2. The host no longer stands up an HTTP server. Its comment claimed the
server was what "keeps the lifecycle-owning process alive"; that is false.
An open undici WebSocket holds the event loop on its own — verified with a
standalone repro where a process with no HTTP server and no timers of its
own stayed up indefinitely on a single WebSocket connection. The server was
therefore serving a second, uncalled copy of the runtime API on port 8300
for no reason.
With the server gone, `createCopilotNodeListener` was the wrong factory —
it builds a request listener purely for its activation side effect. The
host now uses `createCopilotRuntimeHandler` + `ready()`, which is the
documented long-running-host pattern (see fetch-handler.ts). This also
drops `node:http`, `basePath`, and the CHANNEL_PORT env var.
Behaviour is unchanged: same Channel, same agent, same status reporting, and
the same non-zero exit on activation failure.
Verified: 14/14 starters with a `typecheck:channel` script pass; mastra has no
such script by design (166dc94691) and its pre-existing Mastra `Memory` type
error is byte-identical before and after. `npm run channel` exercised on both
failure paths — missing channels.json, and missing INTELLIGENCE_API_KEY with a
name supplied — confirming the new `./channels.mjs` specifier resolves under
tsx as well as tsc. `parity:check` output identical to the pre-change baseline.
Refs #6315
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
31 lines
1.4 KiB
JSON
31 lines
1.4 KiB
JSON
{
|
|
// Unlike every other starter, this config has no matching `typecheck:channel`
|
|
// script in package.json. `channel-host.mts` imports `src/agent.ts`, which
|
|
// transitively pulls in `src/mastra/**` — and that tree has a pre-existing
|
|
// `Type 'Memory' is not assignable to type 'MastraMemory'` error
|
|
// (src/mastra/agents/index.ts:18) unrelated to the Channel host. TypeScript
|
|
// follows imports regardless of `include`, so `tsc -p tsconfig.channel.json
|
|
// --noEmit` can never pass here and there is no scoping fix. This config is
|
|
// still used by the `channel` script (via `tsx --tsconfig`), which only
|
|
// needs it for module resolution, not a clean typecheck.
|
|
"compilerOptions": {
|
|
"target": "es2022",
|
|
"module": "esnext",
|
|
"moduleResolution": "bundler",
|
|
"esModuleInterop": true,
|
|
"skipLibCheck": true,
|
|
"strict": true,
|
|
// mastra-specific addition (not in the reference tsconfig.channel.json):
|
|
// src/agent.ts pulls in src/mastra/**, which uses the "@/*" alias
|
|
// internally (e.g. src/mastra/agents/index.ts imports "@/mastra/tools").
|
|
// Without this, both tsc and tsx fail to resolve that import — verified
|
|
// by running `npm run channel`, which crashes with
|
|
// "Cannot find module '@/mastra/tools'" without it.
|
|
"baseUrl": ".",
|
|
"paths": {
|
|
"@/*": ["./src/*"]
|
|
}
|
|
},
|
|
"include": ["channel-host.mts", "channels.mts", "src/agent.ts"]
|
|
}
|