-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Introduce SyncResponseCache and add /sync response cache timeout #9739
Introduce SyncResponseCache and add /sync response cache timeout #9739
Conversation
(this is a bit over the 200-LoC limit, but 135 lines of these come from |
@@ -0,0 +1 @@ | |||
Added experimental support to cache `/sync` responses with config key `experimental_features.sync_cache_timeout_ms` (in milliseconds). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Do we announce experimental settings like these? Is this even experimental?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well yes, we announce experimental features. I don't think this should be one though. Experimental features are more appropriate when we are making changes to the Matrix protocol; this is all internal to Synapse.
If it needs shaking out before releasing (and I'm not convinced it does), we can do that with test deployments using branches rather than with feature flags.
# (and log it) | ||
res = cond(result) # type: Any | ||
except Exception: | ||
logger.exception( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.exception
because then it throws it to sentry, i think this is pretty sentry-worthy
) | ||
# Return concrete boolean value based on falsy or truthiness. | ||
# If this raises, then so be it, then this value wasn't ever supposed to be true" or "false" | ||
# anyways, then have it be a scream test. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could be more correct by wrapping a try
-catch
around this, but i think that'd be a bit too over-cautious, i dont know what situations could cause bool()
to raise, but coupled with the limited use, i think this is fine.
Still added a comment, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Yes, i'd like it to be this "correct")
return res | ||
|
||
# Copy this method wholesale from ResponseCache to be able to alter the inner `remove` function | ||
def set(self, key: T, deferred: defer.Deferred) -> defer.Deferred: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I couldn't not copy this without editing ResponseCache
to use a method instead of the ::{{remove}}
closure, I didn't wanna touch ResponseCache
, so i just copied this part.
Should I make ResponseCache.set
more generic to allow for it's "remove" closure to be class-defined, or is this okay? (Could add a little bit more maintenance burden to leave it like this)
CALLBACK = lambda: OBJ | ||
|
||
# An object, can be equalized to itself | ||
OBJ = {0} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All that matters is that i have something with an identifier that x == x
, so i can easily boilerplate it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well, I hear your point that you don't want to merge this with ResponseCache, but forking the code (even via a subclass) is a poor solution here: it means we have twice as much stuff to maintain, and having two similar-but-different things is always a recipe for confusion. (Haven't you complained about the two HttpClient implementations in the past?)
I don't really think this is the right solution, and I'm not inclined to accept it. The best I can suggest is waiting for now, and I'll try to put up a PR with my suggested approach and we can try to agree as a group which is the right way forward.
@@ -0,0 +1 @@ | |||
Fix #8518 and #3880. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These won't get auto-linked by towncrier. Please spell out the bugs you are fixing - linking back to the GH issue number isn't normally necessary because anyone who is really interested can follow the link to the PR and thence to the GH issues.
@@ -0,0 +1 @@ | |||
Added experimental support to cache `/sync` responses with config key `experimental_features.sync_cache_timeout_ms` (in milliseconds). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well yes, we announce experimental features. I don't think this should be one though. Experimental features are more appropriate when we are making changes to the Matrix protocol; this is all internal to Synapse.
If it needs shaking out before releasing (and I'm not convinced it does), we can do that with test deployments using branches rather than with feature flags.
I've finally put up my counter-proposal at #10157. |
Thanks, i'll close this PR so that all attention can be focused on that one. |
This is a compromise between #9358's initial handling and the subsequent discussion for semantics (continuing in #9525).
This PR introduces a subclass to
synapse.util.caches.response_cache.ResponseCache
that adds thewrap_conditional
behaviour that is applicable for/sync
; the Very First Caller to thewrap*
function gets to decide the condition-check function for it's result, whether or not it'll instantly expire.This PR also adds an experimental config key:
sync_cache_timeout_ms
, the new cache timeout (in ms) for/sync
results to expire (based on their initial arguments).A few notes
I'll restate it; This PR is a compromise, I would want to continue the discussion in #9525 first, but I don't want to have that bog the fix for #8518, thus this PR adds an explicit subclass to signal that.
I will not merge
SyncResponseCache
withResponseCache
because of that, because I would want to have the discussion in #9525 first.SyncResponseCache.wrap_conditional
's behaviour is custom to/sync
.Pull Request Checklist
EventStore
toEventWorkerStore
.".code blocks
.Fixes #8518
Fixes #3880
Signed-off-by: Jonathan de Jong <[email protected]>