[jeffwall-curlewlabs]

0.2.3 doubled a busy call's attempts, to eight, and each attempt can still run to GH_TIMEOUT_SECONDS. With that at 60s, a call whose every attempt stalls took 8 x 60 + 45 = 525s to fail, where 0.2.2 took 4 x 60 + 85 = 325s. A workflow that sized its slot or record job's timeout-minutes around one failing call could then see the job cancelled at its cap during an API outage, instead of failing with a message. A job reading the ledger once per leg, under a cap sized for 0.2.2, no longer held two such calls.

Change

• GH_TIMEOUT_SECONDS goes from 60 to 30. The same call now fails in 8 x 30 + 45 = 285s, or about 345s with a rate-limited answer and its 60s wait. That is back near 0.2.2's figure, so a cap sized for 0.2.2 holds again.
• A healthy call still has room. GitHub ends any request that takes it more than 10 seconds to process (REST troubleshooting docs, "Request timeouts"), and these calls are single requests or a page or two.
• The constant's comment now says it is spent once per attempt, so anyone sizing a job timeout counts every attempt the retries allow.
• The live job's cap goes back to its pre-0.2.3 20 minutes, which holds two such calls with room to spare.

A shorter timeout adds no requests in the healthy path. The rate-limit handling is unchanged: one retry, after GitHub's documented minimum wait of a minute.

I ran these on a Mac: the unit tests on Python 3.14, ruff format --check, ruff check, mypy and actionlint. CI runs the live check.

The version goes to 0.2.4.