HTTP client connection pool timeouts causing EndOfStream #21316

Activity

1. kassane

   added

   bugObserved behavior contradicts documented or intended behaviorObserved behavior contradicts documented or intended behavior

   on Sep 5, 2024
2. zadockmaloba commented on Oct 4, 2024

   

   zadockmaloba

   on Oct 4, 2024

   More actions

   Experienced something similar. Happens when fetching nested dependencies.

   E.g libpq - has dependencies on openssl, zstd and zlib

   When building it as a standalone it fetches its dependencies correctly. But when we add libpq as a dependency in another project it fails to fetch. (on Linux at least, works fine on macOS Sonoma)

   

   I have not looked deep into it but I think the issue comes when the url has git+https prefix
3. zadockmaloba commented on Oct 6, 2024

   

   zadockmaloba

   on Oct 6, 2024

   More actions

   Check on this: git: fatal: Could not read from remote repository

   It may actually be an ssh issue and not a zig fetch issue. At least it solved the issue for me
4. agagniere commented on Oct 11, 2024

   

   agagniere

   on Oct 11, 2024

   Last edited by agagniere

   More actions

   @zadockmaloba I reproduced your issue here (only on Mac for some reason).

   I then realised the difference between zstd and the other dependencies:

   OK:

    .url = "git+https://github.com/allyourcodebase/zlib?ref=1.3.1#0918....",
   

   Not OK:

   .url = "git+https://github.com/allyourcodebase/zstd.git?ref=1.5.6-1#324a...",
   

   Notice the extra .git !

   Removing the .git solved the issue : after

   👍React with 👍2Reacted by Zadock Maloba and tiawl
5. ianprime0509 commented on Oct 12, 2024

   

   ianprime0509

   on Oct 12, 2024

   Contributor

   More actions

   @zadockmaloba regarding

   It may actually be an ssh issue and not a zig fetch issue.

   Zig's git+http(s) fetch support does not use SSH or even the git binary in any way, so any Git SSH configuration will not affect the fetch process for Git dependencies.

   ---

   @agagniere Zig supports fetching both git+https://github.com/allyourcodebase/zstd and git+https://github.com/allyourcodebase/zstd.git; running zig fetch with both URLs will produce the same output. (This is because GitHub accepts both repository paths without redirecting, not because of any special behavior in Zig)

   ---

   The reason it may seem like certain solutions are working is because this issue is very sporadic and can't be reproduced 100% consistently: even with the GitHub Actions run linked in the issue description, the next attempt of the same run succeeded: https://github.com/allyourcodebase/boost-libraries-zig/actions/runs/10722077115

   I tried to investigate this a bit further: I hacked together an ugly patch to get std.crypto.tls.Client to write its keys to an SSLKEYLOGFILE so Wireshark would be able to decrypt the TLS traffic, and I ran zig build --fetch on the provided project a few times until it failed to fetch some of the packages. In all three failed package fetches I've reproduced so far, what happened is the initial /info/refs request (used to discover Git server capabilities) was sent on a reused connection which the server appears to have already attempted to close, e.g.:

   

   I'm not at all knowledgeable when it comes to low-level networking stuff, though, so unfortunately this is as far as my investigation has gotten so far.

   👍React with 👍3Reacted by Zadock Maloba, Antoine Gagniere and Matheus C. França
6. ianprime0509 commented on Oct 12, 2024

   

   ianprime0509

   on Oct 12, 2024

   Contributor

   More actions

   I'm not sure how I didn't notice this when I was debugging last night, but the server closing the connection is occurring 30 seconds after the last activity on the connection, so this seems to be a case of the server enforcing an idle timeout on the connection and closing it:

   

   But the connection remains in the pool, and is reused for the next request despite being closed. So, in other words, there needs to be some sort of check when acquiring a connection from the pool to make sure that it's still valid to use (and/or enforce an idle timeout within the pool to proactively evict connections which are likely to be unusable).

   👍React with 👍1Reacted by Antoine Gagniere
7. arafel commented on Oct 18, 2024

   

   arafel

   on Oct 18, 2024

   More actions

   If it helps anyone, currently I can reproduce this every time:

   $ zig fetch --save=network git+https://github.com/ikskuh/zig-network
   error: unable to discover remote git server capabilities: TlsInitializationFailed
   

   Distributor ID: Ubuntu
   Description: Ubuntu 20.04.6 LTS
   Release: 20.04
   Codename: focal

   (x86_64)
8. ianprime0509 commented on Oct 19, 2024

   

   ianprime0509

   on Oct 19, 2024

   Contributor

   More actions

   @arafel that is most likely unrelated to the original issue here (EndOfStream vs TlsInitializationFailed), especially if you're able to reproduce it every time with a single dependency having no transitive dependencies. My first thought would be to check whether your system CA certificates are properly installed (on Ubuntu, the ca-certificates package): on a fresh Ubuntu 20.04 Docker container, ca-certificates is not installed by default, and I can reproduce your issue, but after installing ca-certificates it works fine. See also #14168 for a proposal which might improve this situation in the future, if that turns out to be your issue.
9. andrewrk

   changed the title [-]Zig fetch: Unable to discover remote git server capabilities[/-] [+]HTTP client connection pool timeouts causing EndOfStream[/+] on Nov 1, 2024
10. andrewrk

    added

    standard libraryThis issue involves writing Zig code for the standard library.This issue involves writing Zig code for the standard library.

    on Nov 1, 2024
11. andrewrk

    added this to the 0.15.0 milestone on Nov 1, 2024
12. cztomsik commented on Aug 12, 2025

    

    cztomsik

    on Aug 12, 2025

    More actions

    I think I am experiencing this too (getting EndOfStream, after the app is running for some time in Zig 0.14.1) but also my main process forks itself into several children and that might be a problem too. I will try to switch back to curl and see if it solves the issue (and report here).
13. Anton-4

    added a commit that references this issue on Sep 1, 2025

    try without .git

    ...

    e140bce
14. Anton-4

    added a commit that references this issue on Sep 9, 2025

    Roc platform host shim (#8214)

    ...

    cb42d26
15. zzstoatzz

    added a commit that references this issue on Jul 7, 2026

    fix(db): evict poisoned keep-alive connections and retry (ziglang/zig…

    ...

    7a5efff
16. tkdailey11

    added a commit that references this issue on Sep 24, 2026

    Retry libghostty dependency fetches

    ...

    6f3057c
17. andrewrk commented on Oct 11, 2026

    

    andrewrk

    on Oct 11, 2026

    Member

    More actions

    https://codeberg.org/ziglang/zig/issues/37195
18. andrewrk

    closed this as completedon Oct 11, 2026