Consistency for how verify_request.deferred is called

Define that it is run with no log context, and make sure that happens.

If we aren't careful to reset the logcontext, we can't bung the deferreds into
defer.gatherResults etc. We don't actually do that directly, but we *do*
resolve other deferreds from affected callbacks (notably the server_to_deferred
map in _start_key_lookups), and those *do* get passed into
defer.gatherResults. It turns out that this way ends up being least confusing.
This commit is contained in:
Richard van der Hoff 2017-09-20 01:32:42 +01:00
parent 3b98439eca
commit 2a4b9ea233
1 changed files with 17 additions and 13 deletions

View File

@ -57,7 +57,8 @@ Attributes:
json_object(dict): The JSON object to verify.
deferred(twisted.internet.defer.Deferred):
A deferred (server_name, key_id, verify_key) tuple that resolves when
a verify key has been fetched
a verify key has been fetched. The deferreds' callbacks are run with no
logcontext.
"""
@ -284,6 +285,7 @@ class Keyring(object):
if not missing_keys:
break
with PreserveLoggingContext():
for verify_request in requests_missing_keys.values():
verify_request.deferred.errback(SynapseError(
401,
@ -294,6 +296,7 @@ class Keyring(object):
))
def on_err(err):
with PreserveLoggingContext():
for verify_request in verify_requests:
if not verify_request.deferred.called:
verify_request.deferred.errback(err)
@ -714,6 +717,7 @@ class Keyring(object):
def _handle_key_deferred(verify_request):
server_name = verify_request.server_name
try:
with PreserveLoggingContext():
_, key_id, verify_key = yield verify_request.deferred
except IOError as e:
logger.warn(