Services like RESTBase currently assume that reads from the API are not significantly affected by slave lag. We can't easily use the chronology protector to avoid incorrect results, as this would mix authentication with chronology protection. This could potentially lead to protected or otherwise personalized content being returned in an otherwise public wiki, which in turn could cause information leaks in RESTBase and caches.
One option of addressing this issue might be to decouple the chronology protector from authentication, perhaps by using separate cookies. This way, services like RESTBase could forward the chronology protector cookie without also enabling authentication in backends.
## Example use cases
- A user hits 'edit' using VE right after saving an article, and before the MySQL slave has caught up. When replication lag is elevated, this is causing Parsoid parse failures.