Expiring stickiness mid-request/job/console

[ankane]

Hi, it looks like in #194, the decision was made to freeze time when the context is initialized. In the context of stickiness, this means:

• Expiration starts when the request is completed
• Stored items do not expire mid-request/job/console
• Staged data never expires

From my perspective, none of these seem super intuitive or desirable. Are you open to revisiting this? I'm happy to put together a PR if we want to proceed. Here's what I would expect the behavior to be if master_ttl is 5 (whether run in request, job, or console):

User.create! # primary
sleep(5)
User.last # replica

[bleonard]

Interesting. What is your use case? I expect that it is not a normal web request.

I actually saw it an intuitive that once a request sticks, it sticks for the whole time. One person's intuitive can easily be someone else's crazy, of course. Overall, my mind was blown a bit with possibly varying degrees of sync-ness within the request.

Just thinking more about it, if there was to be a clock ticking, we'd want to make sure it would take transactions into consideration. One danger of the naive approach (last "master" SQL call made) might be a long request in a transaction. This wouldn't start syncing over until the COMMIT. So we'd want to handle that.

[ankane]

I was thinking console operations or long running rake tasks/jobs primarily. Once a write happens, it'll never unstick. Good point about transactions.

[bleonard]

We have master stuck automatically on all of our rake jobs just from seeing a few issues over the years.