Rapid authenticated requests fail sometimes

[Skye Welch]

Not sure about the root cause with this one. I double checked that Chomp is setting cookies correctly across sessions, and it is.

Possel responses differ based on if the requests are made rapidly after each other, after reauthentication. Chomp requests /server/all, /buffer/all and /user/all (in that order/concurrently) when showing the Overview screen. If a cached cookie is used, the requests don't come back empty. However, if a fresh cookie is requested, rapid requests after that result in 302 redirects to a 304 session response (and this causes Chomp to interpret the response as empty).

Doing Servers-Buffers-Users just after authentication seems to result in around a 50/50 chance that each of the responses is 302-304.

Adding a 1 second sleep between Auth-Servers-Buffers-Users makes Possel always return 304s (as expected).

Here are some Possel debug logs based on the three different behaviours: https://gist.github.com/carrotengineer/6936eccaded32f37be66

[Kit Barnes]

Could you provide a quick sh script that demonstrates this using curl?

[Kit Barnes]

Almost certainly a race condition; are you waiting for the response from POST /session before the GET requests? (I imagine you are but I should probably rule out the easier client bugs)

[Kit Barnes]

Note: the 302s indicate that your login token is considered invalid.

[Skye Welch]

I double checked the client code to see what cookies were getting set for requests, and it seems to be reporting the right stuff (and is definitely doing these requests after a successful auth).

On another note, it would be nice for the server to report some sort of HTTP auth error rather than a 302.

[Skye Welch]

Here's a log capturing the issue with database logging enabled. It looks like the token is correct in all cases.

https://gist.github.com/carrotengineer/2a270a9fcb8f19a4c2fe

[Skye Welch]

This now appears to be a race condition in Apple's NSHTTPCookie deletion logic. Can't replicate on Possel any more after lazily constructing a session manager on the client (shared across requests) rather than a new one for each request.

[Kit Barnes]

Probably a client bug, reopen if anyone else has a similar issue.