Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Goal
Properly synchronize the update and fetching of network calls. The previous strategy only accounted for the modification of the network call storage, but left limits tracking and limit overage reporting open to race conditions. This change makes sure that while a network call is being logged, we can't fetch a current snapshot for the session payload.
Also, we were trying to be clever about when when to lock when we take the snapshot, but it just didn't work (i.e. the things can change once the calls were fetched but before the payload is returned). As much as we can, we put work outside the synchronization block if we could (i.e. when we validate the staleness of the cache, which should not be a problem now), but in most cases, the locking isn't too bad (i.e. cache read and limits overage data construction), and all we're blocking are background threads. So this should be OK? *sweat_smile
Testing
Existing tests pass. The stateless internal error was happening once every ~650 session or so, and this change should bring it down to 0