Commits on Jun 10, 2026

1. Retry transient full-scan upload failures (502/503/504/408, dropped c… …

   …onnections) (#232)
   
   * Retry transient full-scan upload failures (502/503/504/408, dropped connections)
   
   A full-scan upload can fail transiently at the gateway/connection level -
   an HTTP 502/503/504/408, a dropped or reset connection, or a client-side
   timeout - without the server having created the scan. The CLI previously
   made exactly one attempt, so an entire run (including a completed
   reachability analysis) died on a single transient failure even though a
   retried upload almost always succeeds.
   
   create_full_scan now retries the fullscans POST up to 3 total attempts with
   increasing waits (~10s, then ~30s, plus jitter) on transient failures only:
   APIBadGateway (502), APIConnectionError, APITimeout, and catch-all APIFailure
   whose embedded original_status_code is 408/503/504. Dedicated 4xx classes,
   catch-all 400s, and error payloads are never retried. In these failure modes
   the server never finished reading the request body, so no scan was created
   and a retry does not duplicate one; in the rare case where a gateway timeout
   races a request the server later completes, the extra scan is benign and
   superseded by the retry (as if the CLI had run twice).
   
   The retry loop lives inside the existing try/finally so the brotli-compressed
   .socket.facts.json.br temp files survive until every attempt has finished;
   fullscans.post rebuilds its lazy file loaders from the plain paths on every
   call, so re-invoking it per attempt is safe.
   
   Assisted-by: Claude Code:claude-opus-4-8
   
   * docs: drop the 'retry almost always succeeds' claim from retry comments
   
   * Move transient-error classification into the SDK; simplify retry loop
   
   Address review feedback on the upload retry:
   
   - The retry decision now delegates to APIFailure.is_transient_error()
     (socketdev>=3.3.0, SocketDev/socket-sdk-python#93), which classifies
     by the HTTP status code the SDK records when raising. The CLI no
     longer encodes the SDK's exception hierarchy or parses status codes
     out of message text, so SDK restructuring can't silently break the
     classification.
   - The backoff schedule is now the single source of truth for the loop:
     FULL_SCAN_UPLOAD_BACKOFF_SCHEDULE_SECONDS = (10.0, 30.0, None), where
     each entry is the wait before the next attempt and the final None
     re-raises instead of retrying. FULL_SCAN_UPLOAD_MAX_ATTEMPTS is
     computed from its length.
   
   Note: uv.lock is intentionally not regenerated yet - socketdev 3.3.0
   must be released to PyPI first (blocked on socket-sdk-python#93).
   
   * Lock socketdev 3.3.0
   
   socketdev 3.3.0 is now released, unblocking the >=3.3.0 floor bump.

   

   mtorp authored Jun 10, 2026
   Configuration menu

   • View commit details
   • Copy full SHA for 1af7934
   • Browse repository at this point

   Copy the full SHA

   1af7934 View commit details

   Browse the repository at this point in the history