feat(events): a failed step may say when to retry (MODULE_API 1.15.0) #215

wtclaude · 2026-10-15T07:41:34Z

wtclaude commented

2026-10-15 07:41:34 +00:00

Stage 2 of the Rust §14.3 integration plan: core's step retry delay (docs modules/rust/PLAN_REDESIGNS.md §14.3.13, D371). Spec: docs website/MODULE_API.md §1.1 and website/EVENTS.md §F (docs PR alongside).

{ ok: false, retry: true, retryAfterMs } from perform(): the runner retries after that many milliseconds instead of the flat EVENT_STEP_RETRY_MS. Dangerous Treasures' warm-up (stage 5) is the first user.
Clamped, never refused, to 60 000–1 800 000 ms in dispatch.classify. A value that is not a number is dropped and logged, and the flat delay applies. It is read only on the retry shape.
One attempt of EVENT_STEP_MAX_ATTEMPTS, and it degrades the run like any retry. A run that is paused or cancelled during the wait is not retried (findDue reads only running runs).
The run console says when: every step.retry line carries retryAt (plus retryAfterMs when the module gave one), so the line reads "failed, attempt 1 of 3, retrying at 20:10: not ready yet".
MODULE_API 1.15.0, additions only. The engagement manifest is regenerated. Module-uo (^1.10.0) answers none of it and is unaffected; Module-Rust moves to it in stage 5. STEAM_SIGNIN moves to 1.16.0.
Test harness fix: resourcesDb.finishedRunsWithNothingLeft was never stubbed in eventRunner.test.js. Any tick that reached the cleanup sweep with a terminal run waited on the dead pool. The new cancelled-run test was the first test to do that.

Tested: 6 new runner tests (67 in the file) and 1 new client test. Server suite: 2102 pass. The only failures are the two in routeManifest.test.js, and they fail the same way on an untouched main on this machine, because they read the locally installed modules/. Client: 422/422, and the build passes. No routes changed.

AI-assisted: written with Claude Code (disclosed per org policy).

🤖 Generated with Claude Code

https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

Stage 2 of the Rust §14.3 integration plan: core's step retry delay (docs `modules/rust/PLAN_REDESIGNS.md` §14.3.13, D371). Spec: docs `website/MODULE_API.md` §1.1 and `website/EVENTS.md` §F (docs PR alongside). - **`{ ok: false, retry: true, retryAfterMs }`** from `perform()`: the runner retries after that many milliseconds instead of the flat `EVENT_STEP_RETRY_MS`. Dangerous Treasures' warm-up (stage 5) is the first user. - **Clamped, never refused**, to 60 000–1 800 000 ms in `dispatch.classify`. A value that is not a number is dropped and logged, and the flat delay applies. It is read only on the retry shape. - **One attempt** of `EVENT_STEP_MAX_ATTEMPTS`, and it degrades the run like any retry. A run that is paused or cancelled during the wait is not retried (`findDue` reads only running runs). - **The run console says when:** every `step.retry` line carries `retryAt` (plus `retryAfterMs` when the module gave one), so the line reads *"failed, attempt 1 of 3, retrying at 20:10: not ready yet"*. - **MODULE_API 1.15.0**, additions only. The engagement manifest is regenerated. Module-uo (`^1.10.0`) answers none of it and is unaffected; Module-Rust moves to it in stage 5. STEAM_SIGNIN moves to 1.16.0. - **Test harness fix:** `resourcesDb.finishedRunsWithNothingLeft` was never stubbed in `eventRunner.test.js`. Any tick that reached the cleanup sweep with a terminal run waited on the dead pool. The new cancelled-run test was the first test to do that. **Tested:** 6 new runner tests (67 in the file) and 1 new client test. Server suite: 2102 pass. The only failures are the two in `routeManifest.test.js`, and they fail the same way on an untouched `main` on this machine, because they read the locally installed `modules/`. Client: 422/422, and the build passes. No routes changed. AI-assisted: written with Claude Code (disclosed per org policy). 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

wtclaude added 1 commit 2026-10-15 07:41:36 +00:00

feat(events): a failed step may say when to retry (MODULE_API 1.15.0)

PR Checks / bot-tests (pull_request) Successful in 48s

Details

PR Checks / client-build (pull_request) Successful in 59s

Details

PR Checks / server-tests (pull_request) Successful in 6m6s

Details

769794d183

A module's perform() may answer { ok: false, retry: true, retryAfterMs }
and the runner waits that long instead of the flat EVENT_STEP_RETRY_MS
(Rust PLAN_REDESIGNS §14.3.13, D371). Dangerous Treasures' warm-up is the
first user.

- dispatch.classify reads it on the retry shape only, clamped to 60 000 to
  1 800 000 ms; a value that is not a number is dropped and logged, and the
  step retries on the flat delay.
- It is one attempt of EVENT_STEP_MAX_ATTEMPTS and degrades the run like any
  retry. A run paused or cancelled in the wait is not picked up.
- Every step.retry log line now carries retryAt (and retryAfterMs when
  hinted); the run console reads "retrying at 20:10".
- MODULE_API 1.15.0, additions only; the engagement manifest is regenerated.
  Module-uo (^1.10.0) answers none of it and is unaffected.
- Test harness: resourcesDb.finishedRunsWithNothingLeft was never stubbed in
  eventRunner.test.js, so a tick that reached the cleanup sweep with a
  terminal run waited on the dead pool.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

whitlocktech approved these changes 2026-10-15 07:45:09 +00:00

whitlocktech scheduled this pull request to auto merge when all checks succeed 2026-10-15 07:45:14 +00:00

whitlocktech merged commit eb773693d3 into main

2026-10-15 07:47:49 +00:00

whitlocktech deleted branch feat/event-step-retry-after

2026-10-15 07:47:49 +00:00

whitlocktech referenced this issue from a commit

2026-10-15 07:47:51 +00:00

Merge pull request 'feat(events): a failed step may say when to retry (MODULE_API 1.15.0)' (#215) from feat/event-step-retry-after into main

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/website#215