ci(conformance): GHA-native retry for the prod lane (max 2 attempts) + flake annotation

[devin-ai-integration]

Summary

Make the conformance prod lane resilient to transient network blips (real ingest + Query API readback) without touching the runner or the fault lane. The fault-lane job is unchanged and strict; only the prod-lane job's runner step changes.

The prod runner step is now wrapped in nick-fields/retry@v3, pinned to an immutable commit SHA per this repo's action-pinning convention:

- name: Run conformance runner (prod lane)
  uses: nick-fields/retry@ce71cc2... # v3.0.2
  with:
    max_attempts: 2        # retry once, green on a single pass
    timeout_minutes: 10    # per-attempt cap
  command: | node harness/runner/... --lane prod ...

• Green on one pass; the fault lane (separate job) is never retried.
• A retried green is never silent — a follow-up step emits ::warning::raindrop-rust prod lane passed on retry (flake) when total_attempts == 2 && exit_code == 0.
• prod-lane job timeout-minutes raised 15 → 25 so two prod attempts (dominated by the ~30s duplicate-settle window) plus checkout/build setup fit under the ceiling. Fork/secret gating and step-scoped credentials are unchanged.

Part of a coordinated cross-repo change (harness nightly + each SDK's conformance workflow); the runner and per-scenario logic are unchanged.

Validation

• actionlint .github/workflows/conformance.yml → clean
• cargo build --manifest-path conformance/Cargo.toml → Finished (driver builds against the SDK crate)

Link to Devin session: https://app.devin.ai/sessions/95c28c9cbc7e43cd9c6fd83a72e61bad

---

Note

Low Risk
CI-only workflow changes for the prod lane; no SDK, runner, or credential-handling logic changes.

Overview
The prod conformance job now retries transient real-network failures with repo-owned bash instead of a single runner invocation—fault lane behavior is unchanged.

The prod runner step runs up to two attempts with timeout 1200 per attempt, a 15s pause after the first failure, and writes exit_code / total_attempts for the existing summary. A pass on attempt 2 triggers ::warning::raindrop-rust prod lane passed on retry (flake). Job timeout-minutes goes 15 → 50 to cover two capped attempts plus setup; the report step documents exit code 124 as a per-attempt timeout.

^{Reviewed by Cursor Bugbot for commit 22f3f51. Bugbot is set up for automated code reviews on this repo. Configure here.}

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR that start with 'DevinAI' or '@devin'.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[pavel-y-ivanov]

Closing per Pavel's direction: consolidating GHA-native prod-lane retries into a single final PR — invisible-tools/raindrop-sdk-harness#61 (nightly). Per-repo retry stamps are intentionally not landing; if per-repo conformance retries are wanted later, they should come as one reusable-workflow change, not N copies.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 1c8f901. Configure here.}

[cursor]

Soft per-attempt timeout cap

Medium Severity

timeout 1200 sends SIGTERM and then waits for the process to exit. Without --kill-after, a runner that catches SIGTERM for graceful shutdown—or stays blocked on a hung Query API poll during that shutdown—never yields, so attempt 2 never starts and the job only dies at the 50-minute job ceiling. The stated 20-minute per-attempt cap is soft for the hang cases this retry is meant to cover.

 

^{Reviewed by Cursor Bugbot for commit 1c8f901. Configure here.}

[devin-ai-integration]

Fair point — timeout (no --kill-after) sends only SIGTERM, so a process that traps SIGTERM and then hangs would keep the attempt alive until the 50-min job ceiling, defeating the per-attempt cap. In practice the runner is node (and the driver a short-lived child), which terminates promptly on SIGTERM, so the realistic hang case still exits 124 and retries — and the job ceiling is the hard backstop.

That said, timeout --kill-after=60 1200 … (SIGTERM, then SIGKILL 60s later) would make the cap truly hard and is a one-line, low-risk hardening. But the exact timeout 1200 <cmd> form is Pavel's explicit spec across all six PRs, so I don't want to silently deviate on all of them. Flagging for Pavel to confirm — if he's good with it I'll add --kill-after=60 uniformly (and a 137) TIMEOUT (SIGKILL) summary arm alongside the 124) one).

[pavel-y-ivanov]

Shepherd verification: zero nick-fields refs, timeout-minutes 15→50 on retry job, CI green. 1 unresolved thread (timeout lacks --kill-after, SIGTERM-trapping hang could survive to job ceiling) has a verified Devin rebuttal: realistic runner (node/short-lived driver) exits promptly on SIGTERM, job ceiling is the hard backstop for the degenerate case. Approving per standing shepherd criteria.