A successful run printed several lines that described the runtime working
correctly. Most of it was fallout from defaulting the events transport to
WebSockets (#3702): three breadcrumbs written while the transport was opt-in
became default-path output, because each one reported a choice the caller no
longer makes.
- `world-vercel: using ws events transport (…)` ran once per cold start on
every deployment, naming the transport it was always going to use.
- The `projectConfig` proxy fallback warned once per process. That World cannot
hold a socket, so with WS on by default every CLI command and the
observability app warned about a fallback nobody asked for and nobody can act
on. Debug-gated and reworded from "requested but" to "unavailable for".
- The `max_duration` / `auth_expiry` drain notice is routine: the transport
reconnects from the close that follows and no write is lost.
Swept for the same shape elsewhere:
- `world-local`'s queue-concurrency notice fired per message once a fan-out
exceeded the limit — the semaphore doing its job.
- `@workflow/world`'s active-run recovery line printed on every dev-server
restart with work in flight. The re-enqueue *failure* above it stays
unconditional; that one leaves a run unresumed.
- The port-detection diagnostics in `@workflow/utils` keyed off
`NODE_ENV=development`, which is the only environment that reaches them, so
the gate made them unconditional for their whole audience.
All of it moves behind `DEBUG=workflow:*` via a new `debugLog` in
`@workflow/utils`, joining world-vercel's existing `httpLog` and `logRetry`
output under one selector. Warnings and errors are untouched, so a run that
actually goes wrong is no quieter than before — the ws-transport tests that
assert failures are never silent still pass unchanged.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Pranay Prakash <1797812+pranaygp@users.noreply.github.com>
Pranay Prakash