Schedule-triggered sessions cannot park: "Cannot park: no continuation token available"

[jamesdube]

Schedule-triggered sessions can't park: "Cannot park: no continuation token available"

Summary

In eve 0.13.2 (also present on main), sessions started by a cron schedule fail with Error: Cannot park: no continuation token available as soon as the turn loop emits a park action. The dispatcher calls runtime.run({...}) without a continuationToken, the workflow context seeds eve.continuationToken as "", and the driver's park guard rejects the empty token. The run handle has a usable token (run.runId), but it's never written back into the session state, so it can't satisfy the guard.

Reproduction

Any schedule whose first turn needs to park (e.g. an authorization.required gate, or a handler-form schedule waiting for a channel reply) hits this.

1. Define a markdown schedule:

   import { defineSchedule } from "eve/schedules";
   export default defineSchedule({
     cron: "0 9 * * *",
     markdown: "Audit the queue and file a summary for any blocked item.",
   });

2. Trigger it out-of-band in dev:

   curl -X POST http://localhost:3000/eve/v1/dev/schedules/your-schedule

3. Stream the returned session:

   curl -N http://localhost:3000/eve/v1/session/<sessionId>/stream

4. The session terminates with session.failed whose error is Cannot park: no continuation token available.

Expected vs actual

• Expected (per docs/schedules.mdx): A handler-form session "runs on the same durable runtime engine as any other session, so it can park (durably suspend), for instance when the channel handoff is waiting for a Slack reply." Schedule runs that need to park should durably suspend.
• Actual: The first park action fails with the error above; the session terminates instead of suspending.

Root cause (eve 0.13.2, tag eve@0.13.2)

Three pieces conspire:

1. schedule.ts:116-122 — ScheduleDispatcher.runMarkdown calls runtime.run({ adapter, auth, input, mode: "task" }) without a continuationToken.
2. runtime-context.ts:38 — buildRunContext does ctx.set(ContinuationTokenKey, run.continuationToken ?? ""), so the serialized workflow context carries eve.continuationToken = "".
3. workflow-entry.ts:253-262 — the park guard throws when action.sessionState.continuationToken is falsy.

The run.runId fallback exists only on the returned handle (workflow-runtime.ts:113, continuationToken: input.continuationToken ?? run.runId) and is never reflected back into the session state the driver parks on.

The park action is reachable in task mode via canPark being satisfied by hasPendingAuthorization (turn-workflow.ts:77-81), which is how this surfaces even in fire-and-forget task-mode schedules.

On main / 0.16.x the same logic is at workflow-entry.ts:197-204 (with runtime-context.ts:39).

Stack trace

Error: Cannot park: no continuation token available. The channel must post the
first message during the initial turn (anchoring the session) or `send()` must
be called with an explicit continuationToken.
    at runDriverLoop (packages/eve/src/execution/workflow-entry.ts:257)
    at workflowEntry (packages/eve/src/execution/workflow-entry.ts:76)

The guard that fires is the if (!action.sessionState.continuationToken) check on the preceding line.

Workaround (until fixed)

Until this is fixed, two options that don't require parking:

• Drive the entire flow inside a single Workflow tool JavaScript block so subagents complete (done) without crossing a park boundary.
• For handler-form schedules that genuinely need a channel reply, manually seed a non-empty continuationToken before the first park.

Both are band-aids; the fix is to either:

• Have ScheduleDispatcher.runMarkdown seed a real token (run.runId is already computed for the handle), OR
• Have the park guard seed sessionState.continuationToken from the handle's token before checking.

Environment

• eve: 0.13.2 (also present on main)
• Node: 24 (per repo .nvmrc)
• Platform: any (framework code, not platform-specific)

[jamesdube]

I drafted a fix and verified it locally against main (commit 548a233). Posting here for the maintainers — happy to open a PR if this approach is acceptable.

Fix: seed a namespaced placeholder continuation token in ScheduleDispatcher.runMarkdown before calling runtime.run, so the workflow context's eve.continuationToken is non-empty when the driver's park guard first checks it.

diff --git a/packages/eve/src/channel/schedule.ts b/packages/eve/src/channel/schedule.ts
--- a/packages/eve/src/channel/schedule.ts
+++ b/packages/eve/src/channel/schedule.ts
@@ -106,9 +106,19 @@ export class ScheduleDispatcher {
   }

   private async runMarkdown(markdown: string): Promise<Session> {
+    // Schedule-triggered sessions fire without a channel, so no adapter
+    // owns the continuation token. Seed a namespaced placeholder now —
+    // matching the `<adapterKind>:<uuid>` convention the cross-channel
+    // `receive` path uses — so the workflow context's `eve.continuationToken`
+    // is non-empty when the driver's park guard first checks it. Without
+    // this, the guard throws "Cannot park: no continuation token available."
+    // on the first `park` action and the session terminates instead of
+    // durably suspending.
+    const continuationToken = `${SCHEDULE_ADAPTER_KIND}:${crypto.randomUUID()}`;
     const handle = await this.runtime.run({
       adapter: SCHEDULE_ADAPTER,
       auth: SCHEDULE_APP_AUTH,
+      continuationToken,
       input: { message: markdown },
       mode: "task",
     });

Regression test added in packages/eve/src/channel/schedule.test.ts (markdown-form describe block):

it("seeds a non-empty continuationToken for markdown schedules", async () => {
  // Mocks Runtime.run to echo input.continuationToken into the returned
  // RunHandle (mirroring workflow-runtime.ts:113), then asserts:
  //   - runtime.run called exactly once
  //   - runInput.continuationToken is a non-empty string
  //   - it matches /^schedule:<uuid>$/
  //   - the returned Session's continuationToken equals the seeded one
});

Verification on main (commit 548a233):

• pnpm typecheck → 21/21 tasks OK
• pnpm test src/channel/schedule.test.ts → 7/7 tests pass (including the new one)

Rationale: matches the existing <adapterKind>:<rawToken> namespacing used by the cross-channel receive path (send.ts) and session.ts:mintSubagentContinuationToken, and the existing eve:${crypto.randomUUID()} placeholder pattern already used for channel-less initial sessions (eve.ts). namespaceContinuationToken preserves the schedule: prefix correctly when an adapter re-keys on the first turn.

Caveats:

• Markdown (task-mode) path only. The handler-form run path is unaffected — it already seeds its own tokens via the channel's receive hook.
• I did not attempt to test the cross-package integration test (workflow-entry.integration.test.ts) — the unit test exercises the fix at the source. If the maintainers want an integration test that walks through the actual park guard, that's a follow-up.

I can open a PR if useful.