Dear maintainers,
I noticed an issue inside tokenmanager.py for dealing with tearing down observers from incoming_requests. The dispatch_error function calls stopper function on all observers without checking for token, given that the function doesn't have an argument to know which message timed out. If there are multiple observers from the same remote and one of them were timed out, all the observers would timeout without checking the token.
stoppers = []
for key, request in self.outgoing_requests.items():
(token, request_remote) = key
if request_remote == remote:
stoppers.append(
lambda request=request, exception=exception: request.add_exception(
exception
)
)
for (_, _r), (_, stopper) in self.incoming_requests.items():
if remote == _r:
stoppers.append(stopper)
for stopper in stoppers:
stopper()
An example of a scenario is that if the same remote were to subsequently renew its observe session by registering a new one, after cancelling its old observe, the new observe session can accidentally be cancelled too.
Dear maintainers,
I noticed an issue inside tokenmanager.py for dealing with tearing down observers from incoming_requests. The dispatch_error function calls stopper function on all observers without checking for token, given that the function doesn't have an argument to know which message timed out. If there are multiple observers from the same remote and one of them were timed out, all the observers would timeout without checking the token.
An example of a scenario is that if the same remote were to subsequently renew its observe session by registering a new one, after cancelling its old observe, the new observe session can accidentally be cancelled too.