chore: remove the recovery.limboTimeoutMs lever, which never did anything

[edspencer]

What

recovery.limboTimeoutMs / PADDOCK_RECOVERY_LIMBO_MS was parsed (config.ts:1188), defaulted (recovery-config.ts:94), sanitised, resolved per-project, and carried into the web types — and read by nothing. Zero consumers in packages/server/src. It has been inert since #301 introduced it.

The docs were honest about this — "Backstop timer ships in a follow-up". The Settings UI was not: instance-config.ts:332 listed it as an editable: true number field beside levers that work, with nothing to indicate it was a no-op. Anyone who set it got silence and no way to find out. This project's own dev box exports PADDOCK_RECOVERY_LIMBO_MS=60000 and has been getting nothing.

Why remove rather than implement

Its purpose was a backstop for a chat wedged "running" with no way out — notice the silence, surface it as stuck. #528 removed that need: Stop now works during a chat's background phase, so a wedged session is escapable directly from the UI rather than needing a timer to spot it. Implementing a timer nothing is waiting for would be adding a second, weaker answer to a question already answered.

Compatibility — nothing breaks

• sanitizeRecoveryOverride is an allowlist (recovery-config.ts:123), so a limboTimeoutMs: left in a project.yaml or paddock.config.yaml is silently ignored. That is precisely the effect it has today.
• The env var simply stops being read. No validation rejects unknown PADDOCK_* vars.
• No schemaVersion bump. The documented rule (schema-version.ts:32-43) is "Remove a load-bearing key → Yes". This key carried no load — that is the entire premise of the PR. An old reader of a new file defaults it to 0 (off), which is what it always did; a new reader of an old file drops it.

If you provision Paddock with config management, PADDOCK_RECOVERY_LIMBO_MS in your environment is now dead weight and can be dropped.

Removed

config.ts (type + parse), instance-config.ts (the Settings field), recovery-config.ts (type member, default, sanitise, resolve), packages/web/src/lib/types.ts + fixtures, and the docs rows in configuration/chat-recovery.md, configuration/environment.md, architecture/overview.md.

The remaining recovery levers — surfaceKilledTask, autoReDrive, debounceMs, maxRetries — are untouched and still work.

On the tests

Several tests used limboTimeoutMs as an incidental vector rather than testing it. Their intent is preserved, not deleted:

• recovery-config.test.ts proved non-integers are dropped via limboTimeoutMs: 2.5. That coverage moves to its own assertion ({ debounceMs: 2.5, maxRetries: 1 } → drops the 2.5).
• The "accepts 0 for the numeric knobs" case moves from { debounceMs: 0, limboTimeoutMs: 0 } to { debounceMs: 0, maxRetries: 0 }.
• instance-config.test.ts (PUT /api/instance-config: a null on a nonNegInt field writes 0 instead of clearing the override #723, "PUT with null clears a recovery key") keeps two of its three keys — and had to drop this one anyway, since a non-PATCHABLE_KEYS key is now rejected.

Server 2126 passed, web 1774 passed, typecheck clean.

Follow-up to #528. The other outstanding piece of that issue — unlocking the composer during healthy background work — is filed separately.

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying paddock with    Cloudflare Pages

Latest commit:	55dc18c
Status:	✅  Deploy successful!
Preview URL:	https://ad32a828.paddock-7u2.pages.dev
Branch Preview URL:	https://chore-remove-dead-limbo-time.paddock-7u2.pages.dev

View logs