This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
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.
Fix #8518 (sync requests being cached wrongly on timeout) #9358
Fix #8518 (sync requests being cached wrongly on timeout) #9358
Changes from all commits
406c8f1
bbad98c
e8296ff
3b08294
b239033
04c399d
ed39223
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
this should have had a comment. Why does doing this give the right behaviour? (I shouldn't have to go and find the PR that added it, and even having done so it's hard to correlate the description to the code.)
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.
It was described in the PR description, but i'll take it in another PR to add a comment here, i.e. "small fixes for
ResponseCache
"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.
yeah as I said: having to go and find the PR and grok it is a pain.
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.
Alright, i'll add a comment describing what that conditional does 👍
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.
this seems like a dangerous thing to add to the public interface. It seems like it would be very easy to use in racy way.
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.
should i signal that
add_conditional
is private by prefixing it with_
(in a new PR)?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.
since it's only called in one place, I'd just inline 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.
I think this is correct, but I had to go and look up the precedence of
and
vsor
to check it. Please use parens to disambiguate in future.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.
is it correct that the conditional is added when
not result.called
? I'd argue that cachability of the result should be a property of thecallback
being used (and hence set at the same time as that callback is set) rather than any subsequentcallbacks
(which are discarded).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.
operator precedence is
or
->and
->not
, so this is actuallyI had to check after your previous comment, it could actually be
if not result and not result.called
, but becauseresult
can be a plain return value, i need to insert the check toisinstance(..., defer.Deferred)
Yes, the conditional is added only to be executed after the result is called, i do agree that now i realise that any future calls can be like "hey, this shouldn't be cached anyways because the returned value doesn't agree with what i already got from somewhere else", in which case I need to rewrite this to execute the conditional locally whenever it's called, and evict the cache when it's not valid according to the new conditional. (the
callLater
already taking place would simply execute anyways, no way to properly garbage collect that early at that point (to my knowledge), if it was an asyncioTask
, i could also map it somewhere to then.cancel()
it, if this is possible withcallLater
handles or something, please tell me)(this last approach (letting
callLater
still call) could potentially evict a cache early if a subsequent quickwrap
call has the same key, though idk how much of a problem that'd be, seeing as it'd evict cache shortly after the call, and only if;wrap_conditional
with a conditional that evaluates toFalse
wrap_conditional
call and then-immediate cache eviction, a function (within the remaining timeout) callswrap*
with the same key- wait.Oh, this might actually be a problem, if the function (with the same key) hasn't returned yet on the second
wrap*
call, then the previouscallLater
will evict the deferred, which could lead to more wonky stuff, but the fact it evicts a call in flight already bad enough.)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.
as discussed at considerable length in the room: I don't agree with your logic here. I think that supporting multiple
should_cache
callbacks per key significantly complicates the implentation, and semantically is dubious at best.This comment was marked as outdated.
Sorry, something went wrong.
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.
Alright, i'll just make it a simple
Dict[T, Callable]
mapping then 👍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.
Actually, more discussion in #9522 on this.
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 feel like this is duplicating half the logic of
wrap
, which is kinda the worst of all worlds. Could you not makeshould_cache
nullable, and havewrap
callwrap_conditional
rather than the other way around?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 initially did that, but that became a bit of a mess, and you'd had to shift around the positional arguments on any
wrap
calls currently in place.I also didn't wanna make it a keyword argument, because that'd shadow any potential keyword arguments to the inner call. While i know it is trivial to "just add it", i didn't want to because it is non-explicit to anyone not aware of this change to
ResponseCache
, and so it is possible for it to become a bug.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'm not suggesting changing the signature of
wrap
.Wrap would be:
why is that a mess?
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.
hmmm, i'll change it to that in that PR, then 👍