`stack build` (and pretty much any stack command) runs into a connection timeout

#1

I am using NixOS (23.11 unstable). Here is the error:

Error: [S-775]
       Exception while reading snapshot from https://raw.githubusercontent.com/commercialhaskell/stackage-snapshots/master/lts/19/33.yaml:
       
       HttpExceptionRequest Request {
         host                 = "raw.githubusercontent.com"
         port                 = 443
         secure               = True
         requestHeaders       = [("User-Agent","Haskell pantry package")]
         path                 = "/commercialhaskell/stackage-snapshots/master/lts/19/33.yaml"
         queryString          = ""
         method               = "GET"
         proxy                = Nothing
         rawBody              = False
         redirectCount        = 10
         responseTimeout      = ResponseTimeoutDefault
         requestVersion       = HTTP/1.1
         proxySecureMode      = ProxySecureWithConnect
       }
        ConnectionTimeout

in response to stack build launched from a shell configured like so:

{ pkgs ? import <nixpkgs> { } }:
let
  hls = pkgs.haskell-language-server.override { 
    supportedGhcVersions = [ "902" ];
  };
  stack-wrapped = pkgs.symlinkJoin {
    name = "stack";
    paths = [ pkgs.stack ];
    buildInputs = [ pkgs.makeWrapper ];
    postBuild = ''
      wrapProgram $out/bin/stack \
        --add-flags "\
          --nix \
          --no-nix-pure \
          --nix-shell-file=nix/stack-integration.nix \
        "
    '';
  };

in
pkgs.mkShell {
  # Do NOT use `stack`, otherwise system dependencies like `zlib` are missing at compilation
  buildInputs = [ 
    stack-wrapped 
    hls 
    pkgs.haskell.compiler.ghc90 
  ];
  NIX_PATH = "nixpkgs=" + pkgs.path;
}

The wider context of what I am trying to build can be seen here: GitHub - why-not-try-calmer/mongodb at beefed-up-tests-atlas. Pulling my hair on this, any hint highly appreciated.

#2

A half-educated guess:

For the Stackage migration, we have powered down the old snapshot builder […]

It’s really easy to find unexpected data dependencies during a migration, so I have taken the time to document the architecture as I go. Snapshot curation, the process that was just migrated, still relies on some non-migrated components. […] Ideally nobody will ever notice any change during this migration, but if something does go wrong, I want there to be as few moving parts as possible.

DevOps Log, 2023-11-08

…migrations or upgrades - so much fun!

#3

Thanks for replying, thing is, my CI builds just fine from the same files. And if I switch to a different project that I packaged myself, it also works fine. The issue occurs only for that specific package (which I notice doesn’t declare any package.yaml file).

#4

…and neither does the upstream version:

GitHub - mongodb-haskell/mongodb: MongoDB driver for Haskell

What happens if Stack tries to build with that instead?

#5

Stack builds just fine in the CI: for example Beefed up tests · why-not-try-calmer/mongodb@63f1c02 · GitHub

#6

So there’s a difference between stack build being called from a regular shell, and it being called during CI - now it’s just a (tedious) matter of going through the CI build logs to see what that difference is…if it was recorded at all.

#7

I fixed my problem by disabling IPv6. I am torn between relief and disgust.

1 Like
#8

You have posted at existing Stack issue #5994. If anyone knows why disabling IPv6 works, I would be grateful if they could post the explanation at that issue.

#9

  • Mechap:

    I am on arch linux […]

  • chris-martin:

    I have the same problem, on NixOS […]

  • ejconlon:

    FWIW I encountered this error on a Linux machine […]

…all three OSs use Linux as their kernel - has this problem ever appeared on an “un-Linuxed” OS?

#10

Does Network.Socket.getAddrInfo work with IPv6 (only)? :thinking:

#11

I wish I could help but I have no idea.

#12

A good guess, but luckily the only thing that has been migrated so far is purely a background process that could just go offline for a few days with nobody really noticing. I’ll should be a little more explicit about this when I announce further updates!

Fwiw, I also saw these timeouts (while working on the stackage migration, no less) yesterday. When I switched networks (from wifi to moving hotspot), the problem went away.

#13

As I said, a half-educated guess based entirely on the brief mention by you of the snapshot-server powerdown: elementary rudimentary deduction.

Now that is interesting - to “paraphrase” @Vlix:

  • was the wireless network using IPv6?
  • if so, was it in combination with IPv4?

…in other words: is there a difference in protocols between the two networks?

1 Like
#14

Stack should stop using haskell http(s) libraries. They don’t work well.

That’s why cabal and ghcup both shell out to curl/wget. It’s sad, but true.

1 Like
#15

8 posts were split to a new topic: Haskell HTTP(S) libraries don’t work well