fix(batch-core): record checkpoint restoration failures

[kang-heewon]

Closes #3228.

Checkpoint restoration failures now enter the step failure lifecycle after execution startup. The classifier runs once, the execution records failed or retrying, and the caller receives the original error before any reads or writes. Execution startup failures retain their existing boundary, and successful restoration keeps existing checkpoint and progress behavior.

Validation

Elevated profile: persisted execution failure and retry classification. Public declarations, dependencies, and checkpoint formats are unchanged. Includes a batch-core patch changeset.

• Negative control: both new restoration regressions fail before the fix because the classifier is never called; after the fix, 49 package tests pass.
• Package typecheck and lint: PASS. Tests use the real execution manager to verify both terminal and retryable states, exact failure/classifier calls, error identity, preserved checkpoints, and zero reads/writes. A separate regression covers startup rejection.
• Full build: 302/302 tasks. Guarded full typecheck: 328/328 tasks (fresh normal pre-push run). Full test scope: 311/311 tasks (310 cache hits); normal pre-push also passed 311/311 (310 newly executed), with package concurrency and worker limits; source, environment, and timeouts unchanged. Earlier unrelated compiler/browser deadline failures were superseded by passing runs; their cause remains unproven.
• PR companion: architecture policy, public API snapshots, and repository check PASS (28 passed, 1 not applicable).
• Independent defect review and verification: PASS for the final candidate.

Head: fa4fcebcb00698e7c24ef0c3b6a610039570db47
Validated base: c18f79a98336888c44ca6909ff1090c8f06f8b40

Current base drift to 0e786bfbddf6cd983e1e62d88ed0f30d6d2aee9e: HTTP response and metrics grouping changes do not interact with batch/execution failure lifecycle.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[coderabbitai]

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 52 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 2d10bf52-081c-45a4-a679-6f8494dad472

---

📥 Commits

Reviewing files that changed from the base of the PR and between 0e786bf and fa4fceb.

---

📒 Files selected for processing (3)

• .changeset/tidy-cursors-fail.md
• packages/batch-core/src/libs/ChunkExecutor.ts
• packages/batch-core/src/tests/ChunkExecutor.spec.ts

---

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

📊 Benchmark Results

✅ All benchmarks passed

Benchmark	p75	Threshold	Baseline	vs Baseline	Status	Notes
CrocoApp constructor	7.0μs	30.0ms	8.2μs	-13.9%	✅	-
CrocoApp lambdaHandler (10 controllers)	790.8μs	50.0ms	258.4μs	+206.0%	❌	-
Lambda cold-start simulation	1.0ms	80.0ms	418.1μs	+145.1%	❌	-
Lambda cold-start with headers	808.5μs	80.0ms	369.7μs	+118.7%	❌	-
Lambda cold-start with binary body	794.4μs	80.0ms	339.1μs	+134.2%	❌	-
Lambda cold-start with query params	784.3μs	80.0ms	301.3μs	+160.3%	❌	-
Lambda cold-start with authorizer context	751.3μs	80.0ms	299.8μs	+150.6%	❌	-
Lambda cold-start realistic scenario	773.2μs	80.0ms	299.2μs	+158.4%	❌	-
EventBusConfig.start (10 handlers)	3.9μs	10.0ms	1.4μs	+171.2%	❌	-
EventPublisher.publishNow single event	1.9μs	2.0ms	1.7μs	+10.7%	✅	-
DefaultHandlerResolver.resolve × 10	0.1μs	5.0ms	0.1μs	+37.5%	❌	-
Container.get singleton (cold)	41.4μs	5.0ms	70.3μs	-41.1%	✅	-
Container.register × 50 components	1.8ms	10.0ms	3.2ms	-45.7%	✅	-
Container.validate (50 components)	2.0ms	20.0ms	3.4ms	-40.8%	✅	-
Container.get singleton (warm)	0.6μs	500.0μs	1.6μs	-65.6%	✅	-
TelemetryRuntime.init (lambda preset)	7.7μs	200.0ms	1.1ms	-99.3%	✅	-
lambdaPreset config creation	0.8μs	2.0ms	1.4μs	-43.7%	✅	-

_{Updated: 2026-10-11T10:31:24.600Z · Commit: fa4fceb}

[kang-heewon]

The failed core-verification job is caused by the current base's stale Problem registry source location, tracked in #3495. Regeneration on exact base 0e786bfbddf6cd983e1e62d88ed0f30d6d2aee9e changes only RouteCompiler's source line 331 → 332 in the three generated registry artifacts. The unchanged PR head passes the check on its original base. This issue remains scoped to checkpoint restoration failure handling; merge waits for the independent base artifact repair and a passing selected CI lane.

[kang-heewon]

Superseded by #3506 with the same branch and commit, to obtain fresh required PR-event checks after the base registry fix. Manual CI on this head passed, but ordinary merge was denied because this PR retained the old failed candidate status.