[MundVetter]

Adds opt-in, per-step checkpointing for executor-initiated HTTP runs. After each sequential step.run(), the SDK sends its result to the checkpoint API and waits for acknowledgement, then continues to the next step in the same handler invocation. Acknowledged results are available for replay after a retry or worker restart.

We run the underlying implementation in production at Chainfill against a self-hosted Inngest instance. We are sharing this draft for feedback, and would also be happy for it to serve as inspiration or a starting point for a separate implementation that better fits your plans. We would love to see checkpointing supported upstream so we no longer need to maintain a fork.

• Supports sync and async handlers, with client-level configuration and per-function overrides; disabled by default.
• Checkpoints one completed step per request, with bounded retries and signing-key fallback; no executor-to-worker round trip is needed to start the next sequential step.
• Falls back to ordinary execution when checkpointing is unavailable or the request requires executor scheduling.
• Preserves middleware transformations, encryption, replay behavior, and pending deferred operations.
• Adds a cooperative runtime budget that yields between steps.
• Includes unit, real-server replay/crash, and property-based tests; property tests run in the regular unit suite and CI.

The main missing checkpointing optimization is buffering/batching: this implementation does not accumulate several step results or flush them on a timer. It waits for each checkpoint acknowledgement before continuing, so there is still one checkpoint HTTP request per completed step.

Separate scope limits: checkpointing applies to sequential steps in executor-initiated HTTP runs, not Connect or SDK-initiated durable HTTP endpoints. Parallel discovery, sleeps, waits, and function invocations retain normal executor scheduling. Retry invocations conservatively use ordinary execution, and custom input middleware must support repeated calls with newly persisted memos.

Local validation on Python 3.12: 238 unit tests plus 40 subtests, 24 real-server tests against Inngest v1.45.1, and 200 generated property-test cases per sync/async mode passed, along with Ruff and mypy. Inngest Cloud compatibility and the full framework/Python-version matrix have not been verified locally.