Summary
In a custom channel on eve@0.27.0 (deployed on Vercel), a turn sent with a per-message outputSchema never resumes its durable session on follow-up: every follow-up with the returned continuation token silently opens a brand-new session. The identical call without outputSchema resumes perfectly.
Measurements (deployed agent, Vercel, custom channel)
| call shape |
follow-ups resumed |
send({message, outputSchema}, {auth, continuationToken, mode: "conversation"}) |
0 / 23 (10 conversations back-to-back, 3 with 12s pacing between turns) |
send(message, {auth, continuationToken}) — plain string, no schema, no mode |
10 / 10 (5 conversations, session id identical across all turns) |
Sessions DO park in both shapes — session.waiting fires with a continuation token every turn (observed arriving ~120ms after turn.completed). With the schema, presenting that token back opens a new session (session.started every turn); without it, the same token resumes the same session id.
Expected
The docs indicate a per-message outputSchema on a conversation turn is supported, so we expected the returned/parked continuation token to resume the session as it does for plain sends.
Notes that may help
RunMode docs say task runs "must finish within the current invocation and cannot wait for another message" — the observed behaviour is consistent with an outputSchema turn being keyed or treated as task-shaped regardless of mode: "conversation".send() treating an unknown continuation as a new conversation (rather than an error) made this invisible for a while — a resumed: boolean (or an error on unknown token, opt-in) on the send/session result would have surfaced it immediately.- Separately, on the same deployment we see ~8–9% of turns fail with a 502 below the application layer (no application error logged; the durable workflow's steps then complete with 200s). Happy to open that separately with details if useful.
Workaround we shipped
Moved the structured contract from the per-message outputSchema into a tool (defineTool input schema), captured from actions.requested in the channel; plain-string sends now resume.
Environment
eve@0.27.0, Node 24, deployed on Vercel (Fluid Compute), custom channel via defineChannel, model via AI Gateway (anthropic/claude-sonnet-5).
Summary
In a custom channel on
eve@0.27.0(deployed on Vercel), a turn sent with a per-messageoutputSchemanever resumes its durable session on follow-up: every follow-up with the returned continuation token silently opens a brand-new session. The identical call withoutoutputSchemaresumes perfectly.Measurements (deployed agent, Vercel, custom channel)
send({message, outputSchema}, {auth, continuationToken, mode: "conversation"})send(message, {auth, continuationToken})— plain string, no schema, no modeSessions DO park in both shapes —
session.waitingfires with a continuation token every turn (observed arriving ~120ms afterturn.completed). With the schema, presenting that token back opens a new session (session.startedevery turn); without it, the same token resumes the same session id.Expected
The docs indicate a per-message
outputSchemaon a conversation turn is supported, so we expected the returned/parked continuation token to resume the session as it does for plain sends.Notes that may help
RunModedocs say task runs "must finish within the current invocation and cannot wait for another message" — the observed behaviour is consistent with anoutputSchematurn being keyed or treated as task-shaped regardless ofmode: "conversation".send()treating an unknown continuation as a new conversation (rather than an error) made this invisible for a while — aresumed: boolean(or an error on unknown token, opt-in) on the send/session result would have surfaced it immediately.Workaround we shipped
Moved the structured contract from the per-message
outputSchemainto a tool (defineToolinput schema), captured fromactions.requestedin the channel; plain-string sends now resume.Environment
eve@0.27.0, Node 24, deployed on Vercel (Fluid Compute), custom channel viadefineChannel, model via AI Gateway (anthropic/claude-sonnet-5).