Bad C-c handling during 'stack init'

[sjakobi]

(This is a follow up from the discussion in #3055)

~/s/hackage-server (master|✔) $ stack init
Looking for .cabal or package.yaml files to use to init the project.
Using cabal packages:
- hackage-server.cabal
- tests/unpack-checks/missing-configure-0.1.0.0/missing-configure.cabal
- tests/unpack-checks/correct-package-0.1.0.0/correct-package.cabal

Selecting the best among 10 snapshots...

* Partially matches lts-8.5
    ....

Downloaded nightly-2017-03-19 build plan.    
Missing some cabal revision files, updating indices
Selected mirror https://s3.amazonaws.com/hackage.fpcomplete.com/                                 
Downloading timestamp                                                                            
Downloading snapshot                                                                             
Updating index                                                                                   
UpException user interrupt when using mirror https://s3.amazonaws.com/hackage.fpcomplete.com/      
Selected mirror http://hackage.fpcomplete.com/                                                   
Downloading timestamp                                                                            
Downloading snapshot                                                                             
Updating index                                                                                   
Updated package list downloaded                                                                  

Note the line UpException user interrupt when using mirror https://s3.amazonaws.com/hackage.fpcomplete.com/ – this is where I pressed C-c.

I would have expected stack to abort then but it appears as if stack simply retries downloading the index.

[mgsloan]

We don't have any such retry logic, looks like it is an upstream issue with hackage-security: haskell/hackage-security#187

[snoyberg]

I've created a patch for hackage-security which should hopefully address this:

haskell/hackage-security#202

I've also pushed a branch 3073-hackage-security-async-exceptions with commit 4bf68f0, which moves over to this patched hackage-security. It would be great to get some feedback on whether this patch fixes the issues described here.

[snoyberg]

I just tested the repro above: with previous builds of Stack against unpatched hackage-security, hitting Ctrl-C during the Updating index phase causes the output above. With this patched version, the program exits immediately.

[dcoutts]

Thanks for the contributions upstream. I'd suggest to persist with getting the contributions or equivalent fixes into the upstream package as that way everyone benefits from everyone else's improvements.

[borsboom]

It looks like hackage-security-0.5.3.0 includes a file locking fix (although it appears to be different than @snoyberg's contributed fix). Can anyone confirm whether that fixes the problem?

[snoyberg]

I haven't confirmed myself, but it's probably safe to use.

…

On Fri, Mar 30, 2018, 3:17 AM Emanuel Borsboom ***@***.***> wrote: It looks like hackage-security-0.5.3.0 <http://hackage.haskell.org/package/hackage-security-0.5.3.0/changelog> includes a file locking fix (although it appears to be different than @snoyberg <https://github.com/snoyberg>'s contributed fix). Can anyone confirm whether that fixes the problem? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3073 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADBB7NVtxxJis4QkarzQGE0gztp_4Iqks5tjXmJgaJpZM4Mhoxc> .

[snoyberg]

Problem fixed, closing