[sophiecarreras]

Why

The .sdkharness upload.stall check could not run: it skipped with no-client-option because b2sdk's upload read timeout is 128 s (B2Http.TIMEOUT_FOR_UPLOAD) and the simulator refused a stall over 120 s. The simulator now accepts a stall up to 300000 ms (b2-simulator#54, pinned in demand-side-ai#1686 at 57f44c6).

Changes (.sdkharness/tests/resilience-upload.py, changelog fragment only)

• The check stalls the first upload for 130 s (STALL_MS), above the 128 s timeout, and asserts the CLI recovers with a successful upload afterwards.
• CI and GITHUB_REPOSITORY are removed from the CLI's environment so the CI-only short-timeout hook in b2/_internal/_cli/b2api.py never applies; the check exercises the default timeouts a customer has.
• No change to the CLI itself.

Proof

Run with bin/run-resilience.sh --scenario upload.stall B2_Command_Line_Tool from demand-side-ai main (pin 57f44c6), this branch on master 18b37ef, b2 5.0.2:

• Real CLI: PASS, 2 min 10 s.
• Mutant with TIMEOUT_FOR_UPLOAD = 400: FAIL (journal: no successful b2_upload_file after the stall), so the check detects a client whose timeout is longer than the stall.

🤖 Generated with Claude Code

[sophiecarreras]

Review: .sdkharness test and changelog fragment only. STALL_MS 130000 is above b2sdk's 128 s upload timeout; CI/GITHUB_REPOSITORY are dropped from the CLI environment so the CI-only short-timeout hook cannot mask the default timeout; the Skip is removed. Proof: against the simulator at 57f44c6 the check passes in 2 min 10 s, and with TIMEOUT_FOR_UPLOAD patched to 400 it fails ('no successful b2_upload_file after the stall'). All CI checks pass. Merging normally.