[commandline] servers seem not to block waiting for connections

[imalsogreg]

I'm working on the commandline branch. A simple example server such as the one below prints the typical snap startup info to stdout, and then the process immediately ends without writing anything to access.log or error.log:

main = quickServe (writeText "hello")

Steps to reproduce:

1. git clone [email protected]:imalsogreg/snap
2. cd snap
3. git checkout origin/fallthrough
4. git submodule update --init --recursive
5. ./init-sandbox.sh
6. cabal install --only-dep
7. cabal build
8. dist/build/demo/demo -p 8000

[mightybyte]

This wouldn't be that old clock issue that you discovered would it? If so, since there is now a fixed version available, we should definitely add a constraint to leave out the offending versions.

[imalsogreg]

👍 for some constraints than exclude (clock >= 0.5.2 && < 0.7). I don't think that is the issue here though. My clock is at v0.5.1.

[mightybyte]

Just thinking about this a little more...does the issue happen on the master branch? That could help in tracking it down.

[imalsogreg]

The same simple program main = quickHttpServe (writeText $ pack "Hello") runs as usual on the master branch.

[mightybyte]

Does the test suite pass on the commandline branch? Based on the nature of your report here, I would hope the test suite is failing.

[imalsogreg]

Snap testsuite:

I had to update the test suite a little to match the new types in commandline.

Testsuite fails many of the hspec cases with (Connection refused) errors (consistent with the server not staying up long enough to do anything).

snap-server testsuite:

commandline branch: all green! (second file in this gist

[sopvop]

I think the problem is in this being a maybe monad and this not setting port. Can't check this myself right now, unfortunately.

[imalsogreg]

@sopvop Thanks for the lead. Based on that, I tried explicitly setting the default port here to Just 8000. This does causes a port to be picked by default, but doesn't prevent the fallthrough. Also - choosing a port at runtime with the -p 8001 flag, 8001 makes it all the way through and snap does start up on that port - it just doesn't stay up.

Hmm.