Shareable goes down if you just cancel the download

[AlexDaniel]

I don't have a short snippet to reproduce the issue (yet), but it seems that files served with static bring the whole application down if the user decides to cancel the download. No upstream bug report yet.

[AlexDaniel]

Hm. Tried to reproduce it in a single file and couldn't, it works correctly. Maybe the issue is on my side…

[AlexDaniel]

Actually, it works when running shareable locally, but not on the server. Something weird is going on.

[AlexDaniel]

OK, the only thing that is different on the server is that it works through a reverse proxy.

[jnthn]

What's the failure mode? Error? Silent exit? Silent failure to handle more requests? SEGV?

[AlexDaniel]

@jnthn It says connection reset by peer, and that's it (can't handle any subsequent requests, you just keeping waiting for the response). When that happens, the IRC::Client part of the bot also “hangs” kind of (so it eventually pings out).

I just tried reproducing it through a reverse proxy but no luck :( This only happens on the server and I don't know why. I also thought that maybe there's an exception somewhere, but it does not look like there's anything to catch from the user side.

[AlexDaniel]

blocked label removed because there's no upstream bug report.

[AlexDaniel]

FWIW this can't be related to precomp because it's also reproducible when running the bot in unrestricted (with writable filesystem) mode (there were some weird precomp-related issues in the past, but this is not one of them).

[jnthn]

Yes, "connection reset by peer" is what I'd expect to see (I'm quite used to seeing it if doing some kind of load tests and Ctrl+C'ing them). But I've never seen it result in a refusal to process further requests; the error reporting there is per connection.

[AlexDaniel]

Another datapoint: I can reproduce it using Shareable.p6 but without using a reverse proxy (on the server and not locally). I've also tried to disable the IRC functionality, and it does not seem to affect it in any way. During these tests I get operation canceled message (which is probably equally fine). Still investigating…

[AlexDaniel]

Also, I just managed to reproduce it without static (just content is enough), just by hitting ctrl+f5 in the browser rapidly.

Using this info I managed to bisect the code to this line: https://github.com/perl6/whateverable/blob/55e0f437df0a1f0737efc6ff2098304db079a1cb/bin/Shareable.p6#L60

With this line commented out everything is fine. The problem appears if I uncomment it.

It looks like it goes into the route successfully the first time, does everything and returns properly. But on the second request nothing happens at all, it does not even enter that sub.

Golfing it even further, it seems like the existence of run or the existence of get-output in to-full-commit sub makes the difference. So uncommenting both prevents the issue (and breaks the actual code of course): https://github.com/perl6/whateverable/blob/55e0f437df0a1f0737efc6ff2098304db079a1cb/lib/Whateverable.pm6#L451-L462

[AlexDaniel]

OK, so:

my $application = route {
    get sub ($build, :$type=‘rakudo-moar’, :$arch) {
        say ‘enter’;
        $ = run ‘true’;
        say ‘after’;
        content 'text/plain', "Hello!";
    }
}

This is enough to reproduce the issue… The first time you access it you get:

enter
after

Second access gives nothing.

Either I'm completely blind and stupid, or something is really weird here.

[AlexDaniel]

OK! Rakudobug: https://github.com/rakudo/rakudo/issues/1595

[AlexDaniel]

Uh! So now the issue is that it hangs after any fetch, no matter if you cancel it or not. :S