fix(runtime): seal partial thinking before retrying mid-stream network cuts

[chinawch007]

Summary

A thinking-only streaming attempt that died from a retryable network error
ended the turn, while the identical attempt state recovered when the 120s
idle watchdog fired first — in the #4284 incident an ECONNRESET landed
seconds before the watchdog would have, so the same fault got opposite
outcomes depending on which detector noticed it. Recovery safety depends on
what the attempt emitted, not on which side detected the cut.

The plain retryable path now accepts thinking-only attempts under the seal
contract the watchdog path already uses: flushStep() closes the partial
thinking as a message under its own id, the retry streams into a fresh id,
and the sealed fragment stays out of the retried request's provider context.
It carries its own budget (MAX_SEALED_THINKING_RETRIES_PER_STEP = 1) so a
gateway that systematically cuts long thinking streams fails fast instead of
accumulating fragments across the full attempt budget. The new
sealedThinkingRecovery flag is mutually exclusive with the other three
retry paths by construction.

Answer text, tool activity, and provider continuation metadata remain
non-retryable; the watchdog and truncated-stream paths are unchanged.

Fixes#4284

Verification

• npm run format:check — clean (8 formatting nits auto-fixed and folded in)
• npm run lint — 2304 files, no issues
• npm run typecheck
• npm --workspace @maka/runtime run build — clean
• npm --workspace @maka/runtime run test:dist — 3107 tests, 3094 pass, 13 skip

Not run: the full root-level battery (npm run lint, format:check,
workspace-wide tests, knip).

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: ZCode — analyzed the issue, authored the implementation
and tests from that analysis under a plan reviewed by the contributor; every
step was human-reviewed and verified locally.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[hqhq1025]

I did not find a P0-P3 correctness issue in the exact-head change. The new path permits only retryable failures whose physical request emitted thinking but no answer text, tool activity, continuation metadata, or completed step boundary; it seals that fragment under the current message id, rotates the id, and allows one such recovery per provider step. The added tests cover the successful retry, no-output retry, the one-fragment budget, and the continuation-metadata exclusion.

Validation on this exact head passed: clean install, npm run build:test, full repository typecheck, lint, format, git diff --check, and the complete Runtime suite (3081 passed, 13 skipped). The PR is currently CONFLICTING/DIRTY against main and has no hosted test result. I also performed a local semantic conflict resolution that preserves current main’s ordered reasoning-parts accumulator; the merged tree passed build:test, full typecheck, and the complete Runtime suite (3105 passed, 13 skipped). This is therefore a technical code-review GO for the reviewed head, not a merge-ready decision; the author still needs to rebase and obtain current-head hosted checks.

I did not exercise a real paid provider or reproduce the original macOS gateway incident.

Automated review notice: This comment was posted by an automated review agent operated by hqhq1025. It is not an independent human review and does not replace one.

[chinawch007]

Thanks for your attention, resolved the conflicts.

[chinawch007]

Summary

A thinking-only streaming attempt that died from a retryable network error
ended the turn, while the identical attempt state recovered when the 120s
idle watchdog fired first — in the #4284 incident an ECONNRESET landed
seconds before the watchdog would have, so the same fault got opposite
outcomes depending on which detector noticed it. Recovery safety depends on
what the attempt emitted, not on which side detected the cut.

The plain retryable path now accepts thinking-only attempts under the seal
contract the watchdog path already uses: flushStep() closes the partial
thinking as a message under its own id, the retry streams into a fresh id,
and the sealed fragment stays out of the retried request's provider context.
It carries its own budget (MAX_SEALED_THINKING_RETRIES_PER_STEP = 1) so a
gateway that systematically cuts long thinking streams fails fast instead of
accumulating fragments across the full attempt budget. The new
sealedThinkingRecovery flag is mutually exclusive with the other three
retry paths by construction.

Answer text, tool activity, and provider continuation metadata remain
non-retryable; the watchdog and truncated-stream paths are unchanged.

Fixes#4284

Verification

• npm run format:check — clean (8 formatting nits auto-fixed and folded in)
• npm run lint — 2304 files, no issues
• npm run typecheck
• npm --workspace @maka/runtime run build — clean
• npm --workspace @maka/runtime run test:dist — 3107 tests, 3094 pass, 13 skip

Not run: the full root-level battery (npm run lint, format:check,
workspace-wide tests, knip).

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: ZCode — analyzed the issue, authored the implementation
and tests from that analysis under a plan reviewed by the contributor; every
step was human-reviewed and verified locally.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[hqhq1025]

I did not find a P0-P3 correctness issue in the exact-head change. The new path permits only retryable failures whose physical request emitted thinking but no answer text, tool activity, continuation metadata, or completed step boundary; it seals that fragment under the current message id, rotates the id, and allows one such recovery per provider step. The added tests cover the successful retry, no-output retry, the one-fragment budget, and the continuation-metadata exclusion.

Validation on this exact head passed: clean install, npm run build:test, full repository typecheck, lint, format, git diff --check, and the complete Runtime suite (3081 passed, 13 skipped). The PR is currently CONFLICTING/DIRTY against main and has no hosted test result. I also performed a local semantic conflict resolution that preserves current main’s ordered reasoning-parts accumulator; the merged tree passed build:test, full typecheck, and the complete Runtime suite (3105 passed, 13 skipped). This is therefore a technical code-review GO for the reviewed head, not a merge-ready decision; the author still needs to rebase and obtain current-head hosted checks.

I did not exercise a real paid provider or reproduce the original macOS gateway incident.

Automated review notice: This comment was posted by an automated review agent operated by hqhq1025. It is not an independent human review and does not replace one.

[chinawch007]

Thanks for your attention, resolved the conflicts.

[chinawch007]

Summary

A thinking-only streaming attempt that died from a retryable network error
ended the turn, while the identical attempt state recovered when the 120s
idle watchdog fired first — in the #4284 incident an ECONNRESET landed
seconds before the watchdog would have, so the same fault got opposite
outcomes depending on which detector noticed it. Recovery safety depends on
what the attempt emitted, not on which side detected the cut.

The plain retryable path now accepts thinking-only attempts under the seal
contract the watchdog path already uses: flushStep() closes the partial
thinking as a message under its own id, the retry streams into a fresh id,
and the sealed fragment stays out of the retried request's provider context.
It carries its own budget (MAX_SEALED_THINKING_RETRIES_PER_STEP = 1) so a
gateway that systematically cuts long thinking streams fails fast instead of
accumulating fragments across the full attempt budget. The new
sealedThinkingRecovery flag is mutually exclusive with the other three
retry paths by construction.

Answer text, tool activity, and provider continuation metadata remain
non-retryable; the watchdog and truncated-stream paths are unchanged.

Fixes#4284

Verification

• npm run format:check — clean (8 formatting nits auto-fixed and folded in)
• npm run lint — 2304 files, no issues
• npm run typecheck
• npm --workspace @maka/runtime run build — clean
• npm --workspace @maka/runtime run test:dist — 3107 tests, 3094 pass, 13 skip

Not run: the full root-level battery (npm run lint, format:check,
workspace-wide tests, knip).

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: ZCode — analyzed the issue, authored the implementation
and tests from that analysis under a plan reviewed by the contributor; every
step was human-reviewed and verified locally.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[hqhq1025]

I did not find a P0-P3 correctness issue in the exact-head change. The new path permits only retryable failures whose physical request emitted thinking but no answer text, tool activity, continuation metadata, or completed step boundary; it seals that fragment under the current message id, rotates the id, and allows one such recovery per provider step. The added tests cover the successful retry, no-output retry, the one-fragment budget, and the continuation-metadata exclusion.

Validation on this exact head passed: clean install, npm run build:test, full repository typecheck, lint, format, git diff --check, and the complete Runtime suite (3081 passed, 13 skipped). The PR is currently CONFLICTING/DIRTY against main and has no hosted test result. I also performed a local semantic conflict resolution that preserves current main’s ordered reasoning-parts accumulator; the merged tree passed build:test, full typecheck, and the complete Runtime suite (3105 passed, 13 skipped). This is therefore a technical code-review GO for the reviewed head, not a merge-ready decision; the author still needs to rebase and obtain current-head hosted checks.

I did not exercise a real paid provider or reproduce the original macOS gateway incident.

Automated review notice: This comment was posted by an automated review agent operated by hqhq1025. It is not an independent human review and does not replace one.

[chinawch007]

Thanks for your attention, resolved the conflicts.

[chinawch007]

Summary

A thinking-only streaming attempt that died from a retryable network error
ended the turn, while the identical attempt state recovered when the 120s
idle watchdog fired first — in the #4284 incident an ECONNRESET landed
seconds before the watchdog would have, so the same fault got opposite
outcomes depending on which detector noticed it. Recovery safety depends on
what the attempt emitted, not on which side detected the cut.

The plain retryable path now accepts thinking-only attempts under the seal
contract the watchdog path already uses: flushStep() closes the partial
thinking as a message under its own id, the retry streams into a fresh id,
and the sealed fragment stays out of the retried request's provider context.
It carries its own budget (MAX_SEALED_THINKING_RETRIES_PER_STEP = 1) so a
gateway that systematically cuts long thinking streams fails fast instead of
accumulating fragments across the full attempt budget. The new
sealedThinkingRecovery flag is mutually exclusive with the other three
retry paths by construction.

Answer text, tool activity, and provider continuation metadata remain
non-retryable; the watchdog and truncated-stream paths are unchanged.

Fixes#4284

Verification

• npm run format:check — clean (8 formatting nits auto-fixed and folded in)
• npm run lint — 2304 files, no issues
• npm run typecheck
• npm --workspace @maka/runtime run build — clean
• npm --workspace @maka/runtime run test:dist — 3107 tests, 3094 pass, 13 skip

Not run: the full root-level battery (npm run lint, format:check,
workspace-wide tests, knip).

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: ZCode — analyzed the issue, authored the implementation
and tests from that analysis under a plan reviewed by the contributor; every
step was human-reviewed and verified locally.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[hqhq1025]

I did not find a P0-P3 correctness issue in the exact-head change. The new path permits only retryable failures whose physical request emitted thinking but no answer text, tool activity, continuation metadata, or completed step boundary; it seals that fragment under the current message id, rotates the id, and allows one such recovery per provider step. The added tests cover the successful retry, no-output retry, the one-fragment budget, and the continuation-metadata exclusion.

Validation on this exact head passed: clean install, npm run build:test, full repository typecheck, lint, format, git diff --check, and the complete Runtime suite (3081 passed, 13 skipped). The PR is currently CONFLICTING/DIRTY against main and has no hosted test result. I also performed a local semantic conflict resolution that preserves current main’s ordered reasoning-parts accumulator; the merged tree passed build:test, full typecheck, and the complete Runtime suite (3105 passed, 13 skipped). This is therefore a technical code-review GO for the reviewed head, not a merge-ready decision; the author still needs to rebase and obtain current-head hosted checks.

I did not exercise a real paid provider or reproduce the original macOS gateway incident.

Automated review notice: This comment was posted by an automated review agent operated by hqhq1025. It is not an independent human review and does not replace one.

[chinawch007]

Thanks for your attention, resolved the conflicts.

[chinawch007]

Summary

A thinking-only streaming attempt that died from a retryable network error
ended the turn, while the identical attempt state recovered when the 120s
idle watchdog fired first — in the #4284 incident an ECONNRESET landed
seconds before the watchdog would have, so the same fault got opposite
outcomes depending on which detector noticed it. Recovery safety depends on
what the attempt emitted, not on which side detected the cut.

The plain retryable path now accepts thinking-only attempts under the seal
contract the watchdog path already uses: flushStep() closes the partial
thinking as a message under its own id, the retry streams into a fresh id,
and the sealed fragment stays out of the retried request's provider context.
It carries its own budget (MAX_SEALED_THINKING_RETRIES_PER_STEP = 1) so a
gateway that systematically cuts long thinking streams fails fast instead of
accumulating fragments across the full attempt budget. The new
sealedThinkingRecovery flag is mutually exclusive with the other three
retry paths by construction.

Answer text, tool activity, and provider continuation metadata remain
non-retryable; the watchdog and truncated-stream paths are unchanged.

Fixes#4284

Verification

• npm run format:check — clean (8 formatting nits auto-fixed and folded in)
• npm run lint — 2304 files, no issues
• npm run typecheck
• npm --workspace @maka/runtime run build — clean
• npm --workspace @maka/runtime run test:dist — 3107 tests, 3094 pass, 13 skip

Not run: the full root-level battery (npm run lint, format:check,
workspace-wide tests, knip).

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: ZCode — analyzed the issue, authored the implementation
and tests from that analysis under a plan reviewed by the contributor; every
step was human-reviewed and verified locally.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[hqhq1025]

I did not find a P0-P3 correctness issue in the exact-head change. The new path permits only retryable failures whose physical request emitted thinking but no answer text, tool activity, continuation metadata, or completed step boundary; it seals that fragment under the current message id, rotates the id, and allows one such recovery per provider step. The added tests cover the successful retry, no-output retry, the one-fragment budget, and the continuation-metadata exclusion.

Validation on this exact head passed: clean install, npm run build:test, full repository typecheck, lint, format, git diff --check, and the complete Runtime suite (3081 passed, 13 skipped). The PR is currently CONFLICTING/DIRTY against main and has no hosted test result. I also performed a local semantic conflict resolution that preserves current main’s ordered reasoning-parts accumulator; the merged tree passed build:test, full typecheck, and the complete Runtime suite (3105 passed, 13 skipped). This is therefore a technical code-review GO for the reviewed head, not a merge-ready decision; the author still needs to rebase and obtain current-head hosted checks.

I did not exercise a real paid provider or reproduce the original macOS gateway incident.

Automated review notice: This comment was posted by an automated review agent operated by hqhq1025. It is not an independent human review and does not replace one.

[chinawch007]

Thanks for your attention, resolved the conflicts.

[chinawch007]

Summary

A thinking-only streaming attempt that died from a retryable network error
ended the turn, while the identical attempt state recovered when the 120s
idle watchdog fired first — in the #4284 incident an ECONNRESET landed
seconds before the watchdog would have, so the same fault got opposite
outcomes depending on which detector noticed it. Recovery safety depends on
what the attempt emitted, not on which side detected the cut.

The plain retryable path now accepts thinking-only attempts under the seal
contract the watchdog path already uses: flushStep() closes the partial
thinking as a message under its own id, the retry streams into a fresh id,
and the sealed fragment stays out of the retried request's provider context.
It carries its own budget (MAX_SEALED_THINKING_RETRIES_PER_STEP = 1) so a
gateway that systematically cuts long thinking streams fails fast instead of
accumulating fragments across the full attempt budget. The new
sealedThinkingRecovery flag is mutually exclusive with the other three
retry paths by construction.

Answer text, tool activity, and provider continuation metadata remain
non-retryable; the watchdog and truncated-stream paths are unchanged.

Fixes#4284

Verification

• npm run format:check — clean (8 formatting nits auto-fixed and folded in)
• npm run lint — 2304 files, no issues
• npm run typecheck
• npm --workspace @maka/runtime run build — clean
• npm --workspace @maka/runtime run test:dist — 3107 tests, 3094 pass, 13 skip

Not run: the full root-level battery (npm run lint, format:check,
workspace-wide tests, knip).

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: ZCode — analyzed the issue, authored the implementation
and tests from that analysis under a plan reviewed by the contributor; every
step was human-reviewed and verified locally.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[hqhq1025]

I did not find a P0-P3 correctness issue in the exact-head change. The new path permits only retryable failures whose physical request emitted thinking but no answer text, tool activity, continuation metadata, or completed step boundary; it seals that fragment under the current message id, rotates the id, and allows one such recovery per provider step. The added tests cover the successful retry, no-output retry, the one-fragment budget, and the continuation-metadata exclusion.

Validation on this exact head passed: clean install, npm run build:test, full repository typecheck, lint, format, git diff --check, and the complete Runtime suite (3081 passed, 13 skipped). The PR is currently CONFLICTING/DIRTY against main and has no hosted test result. I also performed a local semantic conflict resolution that preserves current main’s ordered reasoning-parts accumulator; the merged tree passed build:test, full typecheck, and the complete Runtime suite (3105 passed, 13 skipped). This is therefore a technical code-review GO for the reviewed head, not a merge-ready decision; the author still needs to rebase and obtain current-head hosted checks.

I did not exercise a real paid provider or reproduce the original macOS gateway incident.

Automated review notice: This comment was posted by an automated review agent operated by hqhq1025. It is not an independent human review and does not replace one.

[chinawch007]

Thanks for your attention, resolved the conflicts.

[chinawch007]

Summary

A thinking-only streaming attempt that died from a retryable network error
ended the turn, while the identical attempt state recovered when the 120s
idle watchdog fired first — in the #4284 incident an ECONNRESET landed
seconds before the watchdog would have, so the same fault got opposite
outcomes depending on which detector noticed it. Recovery safety depends on
what the attempt emitted, not on which side detected the cut.

The plain retryable path now accepts thinking-only attempts under the seal
contract the watchdog path already uses: flushStep() closes the partial
thinking as a message under its own id, the retry streams into a fresh id,
and the sealed fragment stays out of the retried request's provider context.
It carries its own budget (MAX_SEALED_THINKING_RETRIES_PER_STEP = 1) so a
gateway that systematically cuts long thinking streams fails fast instead of
accumulating fragments across the full attempt budget. The new
sealedThinkingRecovery flag is mutually exclusive with the other three
retry paths by construction.

Answer text, tool activity, and provider continuation metadata remain
non-retryable; the watchdog and truncated-stream paths are unchanged.

Fixes#4284

Verification

• npm run format:check — clean (8 formatting nits auto-fixed and folded in)
• npm run lint — 2304 files, no issues
• npm run typecheck
• npm --workspace @maka/runtime run build — clean
• npm --workspace @maka/runtime run test:dist — 3107 tests, 3094 pass, 13 skip

Not run: the full root-level battery (npm run lint, format:check,
workspace-wide tests, knip).

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: ZCode — analyzed the issue, authored the implementation
and tests from that analysis under a plan reviewed by the contributor; every
step was human-reviewed and verified locally.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[hqhq1025]

I did not find a P0-P3 correctness issue in the exact-head change. The new path permits only retryable failures whose physical request emitted thinking but no answer text, tool activity, continuation metadata, or completed step boundary; it seals that fragment under the current message id, rotates the id, and allows one such recovery per provider step. The added tests cover the successful retry, no-output retry, the one-fragment budget, and the continuation-metadata exclusion.

Validation on this exact head passed: clean install, npm run build:test, full repository typecheck, lint, format, git diff --check, and the complete Runtime suite (3081 passed, 13 skipped). The PR is currently CONFLICTING/DIRTY against main and has no hosted test result. I also performed a local semantic conflict resolution that preserves current main’s ordered reasoning-parts accumulator; the merged tree passed build:test, full typecheck, and the complete Runtime suite (3105 passed, 13 skipped). This is therefore a technical code-review GO for the reviewed head, not a merge-ready decision; the author still needs to rebase and obtain current-head hosted checks.

I did not exercise a real paid provider or reproduce the original macOS gateway incident.

Automated review notice: This comment was posted by an automated review agent operated by hqhq1025. It is not an independent human review and does not replace one.

[chinawch007]

Thanks for your attention, resolved the conflicts.

[chinawch007]

Summary

A thinking-only streaming attempt that died from a retryable network error
ended the turn, while the identical attempt state recovered when the 120s
idle watchdog fired first — in the #4284 incident an ECONNRESET landed
seconds before the watchdog would have, so the same fault got opposite
outcomes depending on which detector noticed it. Recovery safety depends on
what the attempt emitted, not on which side detected the cut.

The plain retryable path now accepts thinking-only attempts under the seal
contract the watchdog path already uses: flushStep() closes the partial
thinking as a message under its own id, the retry streams into a fresh id,
and the sealed fragment stays out of the retried request's provider context.
It carries its own budget (MAX_SEALED_THINKING_RETRIES_PER_STEP = 1) so a
gateway that systematically cuts long thinking streams fails fast instead of
accumulating fragments across the full attempt budget. The new
sealedThinkingRecovery flag is mutually exclusive with the other three
retry paths by construction.

Answer text, tool activity, and provider continuation metadata remain
non-retryable; the watchdog and truncated-stream paths are unchanged.

Fixes#4284

Verification

• npm run format:check — clean (8 formatting nits auto-fixed and folded in)
• npm run lint — 2304 files, no issues
• npm run typecheck
• npm --workspace @maka/runtime run build — clean
• npm --workspace @maka/runtime run test:dist — 3107 tests, 3094 pass, 13 skip

Not run: the full root-level battery (npm run lint, format:check,
workspace-wide tests, knip).

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: ZCode — analyzed the issue, authored the implementation
and tests from that analysis under a plan reviewed by the contributor; every
step was human-reviewed and verified locally.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[hqhq1025]

I did not find a P0-P3 correctness issue in the exact-head change. The new path permits only retryable failures whose physical request emitted thinking but no answer text, tool activity, continuation metadata, or completed step boundary; it seals that fragment under the current message id, rotates the id, and allows one such recovery per provider step. The added tests cover the successful retry, no-output retry, the one-fragment budget, and the continuation-metadata exclusion.

Validation on this exact head passed: clean install, npm run build:test, full repository typecheck, lint, format, git diff --check, and the complete Runtime suite (3081 passed, 13 skipped). The PR is currently CONFLICTING/DIRTY against main and has no hosted test result. I also performed a local semantic conflict resolution that preserves current main’s ordered reasoning-parts accumulator; the merged tree passed build:test, full typecheck, and the complete Runtime suite (3105 passed, 13 skipped). This is therefore a technical code-review GO for the reviewed head, not a merge-ready decision; the author still needs to rebase and obtain current-head hosted checks.

I did not exercise a real paid provider or reproduce the original macOS gateway incident.

Automated review notice: This comment was posted by an automated review agent operated by hqhq1025. It is not an independent human review and does not replace one.

[chinawch007]

Thanks for your attention, resolved the conflicts.