We’ve just upgraded our core product from v4.5.12 to v5.8.0 (we had to drop support for Oracle to finally make the jump to a recent ServiceStack release.
We just ran into a weird behaviour of the auto-batch feature on the 5.8 version.
Integrations fetching 400 requests via /json/reply/GetLocationData[] seem to often fail authentication (they can’t find a required request header that contains a session token).
But if the integrations drop their batch size down to 100 requests (and make 4x the number of batched requests), then there is no problem.
Each /GetLocationData response is roughly 1KB of JSON, so I don’t think it a memory issue. And we’ve had integrations running in 400-count-batches for years without issue.
Obviously we are going to try upgrading to the most stable v5.9.x branch, and we still have more debugging to do, but I thought I’d ask if there were any known quirks/bugs that might have been fixed since SS v5.8 was released in Jan 2020.
I just confirmed with some debug logging that it is failing at around request 170-ish of the 400-batch request, because HttpContext.Current (where the session token is stored) is unexpectedly null.
We’ll try to upgrade to a v5.9 release and see if things improve. (I don’t expect much pain moving from 5.8 to 5.9, since that is a much smaller jump.)
This sounds like a different issue, HttpContext.Current would only be null when trying to access it from a non HTTP Worker Request Thread like a background thread which you can’t do.
If the issue is due to an async thread hop where the logical thread state didn’t flow across, it may be resolved in the latest v5.9.3+ on MyGet where manual continuations have been replaced with async/await which resolved a different issue with async batched requests.