Throttle unchanged session store writes

Heinrich Lee Yurequested to merge
hly-throttle-session-writes into master

What does this MR do and why?

While investigating flaky specs, I found out that session data can be overwritten by another concurrent request.

Today, every request reads the session data at the start of the request (to check current user) and then commits it back to Redis at the end of the request even if nothing changed. So something like this can happen:

  1. Both request 1 and request 2 start and reads {} from session
  2. Request 1 updates the session to { admin_mode: true }
  3. Request 1 completes and writes { admin_mode: true } to Redis
  4. Request 2 completes and writes {} to Redis

To reduce the chances of concurrent requests overwriting session data from another request, we throttle writing to the session store when the request does not mutate session data.

This significantly reduces the chances of conflict since we do not mutate session data in many of our requests.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Heinrich Lee Yu

Merge request reports