test: Retry download in get_previous_releases.py #33915

1. 
   maflcko commented at 11:48 am on November 20, 2025: member

   Hopefully fixes #33913 (intermittent download issues)

   If not, the diff there to cache the bins can be considered.

2. test: retry download in get_previous_releases.py fad06f3bb4
3. DrahtBot added the label Tests on Nov 20, 2025
4. 
   DrahtBot commented at 11:48 am on November 20, 2025: contributor

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   Code Coverage & Benchmarks

   For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33915.

   Reviews

   See the guideline for information on the review process.

   Type	Reviewers
   ACK	enirox001, davidgumberg, TheCharlatan, janb84, achow101

   If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

5. in test/get_previous_releases.py:171 in fad06f3bb4

   167@@ -168,7 +168,13 @@ def download_binary(tag, args) -> int:
   168         download_from_url(archive_url, archive)
   169     except Exception as e:
   170         print(f"\nDownload failed: {e}", file=sys.stderr)
   171-        return 1
   172+        print("Retrying download after failure ...", file=sys.stderr)
   

   ---

   ---

   

   enirox001 commented at 5:16 pm on November 20, 2025:

   nano nit: The single retry seems reasonable to start with. If CI flakiness persists after this change, increasing to 2-3 retries or adding exponential backoff can be considered
6. 
   enirox001 commented at 5:18 pm on November 20, 2025: contributor

   ACK fad06f3

   This looks good to me. I tested locally by running the script with valid releases (v25.0, v24.0.1) and an invalid one (v0.1.0) to verify the retry logic works correctly. The retry mechanism should significantly reduce CI failures from transient network issues.

   optional nit: Consider adding an explicit timeout to urlopen() (e.g., timeout=60) to fail faster in case of network hangs, rather than relying on OS socket defaults. This would make the script more predictable and potentially avoid wasting CI time on stuck connections.

   Not blocking since the current retry logic should handle the immediate problem.

7. 
   davidgumberg commented at 6:58 pm on November 20, 2025: contributor

   ACK https://github.com/bitcoin/bitcoin/pull/33915/commits/fad06f3bb436a97683e8248bfda1bd0d9998c899

   Nice! I’ve also had issues with this locally, retrying once seems a good idea.

8. TheCharlatan approved
9. 
   TheCharlatan commented at 9:14 pm on November 20, 2025: contributor

   ACK fad06f3bb436a97683e8248bfda1bd0d9998c899
10. 
    Sammie05 commented at 7:03 am on November 21, 2025: none

    I verified the retry mechanism by testing both successful downloads (v25.0) and failure scenarios (invalid_version_123), the retry logic correctly activates on HTTP 404 errors and provides clear error message

    Fetching: https://bitcoincore.org/bin/bitcoin-core-nvalid_version_123/bitcoin-nvalid_version_123-osx64.tar.gz

    Download failed: HTTP Error 404: Not Found Retrying download after failure …

    Download failed a second time: HTTP Error 404: Not Found

11. 
    janb84 commented at 9:35 am on November 21, 2025: contributor

    ACK fad06f3bb436a97683e8248bfda1bd0d9998c899

    PR adds one retry to download a prev. release.

    The single retry is somewhat crude solution but a good first step to solve the intermitted download issues, good KISS sollution. If this isn’t enough we can always fallback on more elegant solutions, but this also increases the complexity.

12. 
    achow101 commented at 9:34 pm on November 21, 2025: member

    ACK fad06f3bb436a97683e8248bfda1bd0d9998c899
13. achow101 merged this on Nov 21, 2025
14. achow101 closed this on Nov 21, 2025

    ---

15. maflcko deleted the branch on Nov 24, 2025

Contributors
maflcko DrahtBot enirox001 davidgumberg TheCharlatan Sammie05 janb84 achow101

Labels
Tests