[ParidelPooya]

Fixes #1056.

Summary

The MicroVM worker logs a warning when its own SuspendMicrovm call has an unknown outcome. Without a terminate hook, the warning said that the worker refuses jobs. That was false when the refusal had already ended during the call. This PR changes only which text the worker logs. The behavior is unchanged.

Why

1. The warning said: "The worker refuses jobs until the MicroVM resumes, or for 30 seconds."
2. A resume hook during the call ends the refusal of jobs.
3. The 30-second limit of a suspend hook's refusal can also end during the call. This needs a client from createMicrovmsClient that runs past the worker's 10-second abort.
4. After an unknown outcome, the worker starts a new refusal only while suspending is still set.
5. So in these sequences the worker accepts jobs. A job right after the warning gets HTTP 202.
6. The likely sequence is the first one: the worker's own call suspended the MicroVM, and its answer was lost across the freeze.

Changes

• failedCallWarning reads suspending for an unknown outcome. The catch block calls it before the unknown branch acts on the state.
• When the refusal already ended, the warning says: "the suspend call for the idle MicroVM had an unknown outcome. The refusal of jobs already ended during the call, on a resume hook or after 30 seconds. So the worker accepts jobs. It tries the call again one idle time after the call and every job end."
• The idle time cannot start while a job runs. A job can start during the call after a resume hook. So the text names the call and every job end, as the refused-for-now text for the same state does.
• A closed worker starts no idle time. So after close() during the call, the same case says: "… So the worker accepts jobs. The worker is closed, so it does not try the call again."
• The terminating text and the normal unknown text are unchanged.
• The JSDoc of failedCallWarning lists the new cases.
• README item 8 and the listener JSDoc item 8 end with: "A resume hook during the call, or the end of a suspend hook's 30 seconds during the call, has already ended the refusal. The worker then accepts jobs at once, and tries the call again one idle time after the call and every job end."
• The Python worker has the same text. fix(microvm-worker): state that the refusal ended aws-durable-execution-sdk-python#817 makes the same change, with identical texts and conditions.

Testing

• 12 new tests in auto-suspend.test.ts. The three sequences from the issue each assert the full text, one warning, HTTP 202 for a job right after, and the next call one idle time after that job ends.
• Other tests cover the idle time that starts at the call end, the closed variant, a resume hook and then a terminate hook, and a guard that keeps the old text with no hook, with a suspend hook still in effect, and after close() alone.
• A job that still runs at the outcome: the warning has the new text, and the next call comes one idle time after the job ends.
• A resume hook and then a suspend hook during the call, and two suspend hooks with the call ending during the second refusal: both keep the refusal text and refuse jobs for 30 seconds after the call.
• 6 of the new tests fail on main. With the old texts expected, all tests pass on main. So calls, statuses, and timings are unchanged.
• Removing or inverting each new condition fails at least one test.
• npm test in the package passes 292 tests. Coverage rose from 96.57 % to 96.59 % of statements, and from 92.53 % to 92.61 % of branches.
• npm run build, the package lint, the root npm run lint, and npm run format:check pass.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[yaythomas]

[github-actions]

Codex AI review

No actionable findings. The SDK invariants and protected contract tests are unchanged. Tests were inspected but not run because repository code execution was prohibited; runtime behavior remains unverified.

Reviewed commit 4d5aa93bea81a8355f0e468b1a2b212ca53dcc34. Workflow run