Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Log looping call exceptions #4008

Merged
merged 4 commits into from
Oct 9, 2018
Merged

Conversation

erikjohnston
Copy link
Member

If a looping call function errors, then it kills the loop entirely.
Currently it throws away the exception logs, so we should make it
actually log them.

Fixes #3929

If a looping call function errors, then it kills the loop entirely.
Currently it throws away the exception logs, so we should make it
actually log them.

Fixes #3929
@erikjohnston erikjohnston requested a review from a team October 5, 2018 10:25
@hawkowl
Copy link
Contributor

hawkowl commented Oct 8, 2018

Should we not restart the looping call, vs logging and then breaking?

@hawkowl
Copy link
Contributor

hawkowl commented Oct 8, 2018

(I guess, though, we do catch it lower, so this actually shouldn't ever happen. Hmmmmm.)

@functools.wraps(f)
def wrap(*args, **kwargs):
try:
logger.info("Running looping call")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't seem like a useful thing to log at INFO.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Woops. That's me failing to remove my debugging.....

@erikjohnston
Copy link
Member Author

Yeah, opinions welcome if we just want to restart the loop. I'm a bit cautious about changing the behaviour vs. the in built twisted one.

@@ -66,7 +67,7 @@ def looping_call(self, f, msec):
f(function): The function to call repeatedly.
msec(float): How long to wait between calls in milliseconds.
"""
call = task.LoopingCall(f)
call = task.LoopingCall(_log_exception_wrapper(f))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a reason for doing this rather than adding an errback to the deferred returned by call.start?

def wrap(*args, **kwargs):
try:
logger.info("Running looping call")
return f(*args, **kwargs)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this won't actually catch any asynchronous failures.

@richvdh
Copy link
Member

richvdh commented Oct 8, 2018

given this is intended as a last resort to catch utter brokenness, I'd advocate not restarting the broken task, and rather requiring that looping calls not to return failures if they want to keep running.

@erikjohnston erikjohnston force-pushed the erikj/log_looping_exceptions branch from 572eab2 to f5777ce Compare October 8, 2018 12:29
@erikjohnston erikjohnston force-pushed the erikj/log_looping_exceptions branch from f5777ce to 8a1817f Compare October 8, 2018 12:29
@erikjohnston erikjohnston requested a review from a team October 8, 2018 12:51
Copy link
Member

@richvdh richvdh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also, the old log_failure is still sitting around unloved.

@@ -112,17 +114,30 @@ def batch_iter(iterable, size):
return iter(lambda: tuple(islice(sourceiter, size)), ())


def _log_exception_wrapper(f):
"""Used to wrap looping calls to log loudly if they get killed
def make_log_failure_errback(msg, consumeErrors=True):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could you not have msg and consumeErrors as params to log_failure and then just do addErrback(log_failure, msg) ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

... yes.

This PR is going terribly.

@erikjohnston erikjohnston requested a review from a team October 8, 2018 13:52
Copy link
Member

@richvdh richvdh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks plausible. I assume you've tested the log_failure func does what you expect, somehow?

@erikjohnston
Copy link
Member Author

looks plausible. I assume you've tested the log_failure func does what you expect, somehow?

Yup, and this time I actually tried an async failure!

@erikjohnston erikjohnston merged commit 9eb1a79 into develop Oct 9, 2018
michaelkaye added a commit that referenced this pull request Oct 22, 2018
**Warning**: This release removes the example email notification templates from
`res/templates` (they are now internal to the python package). This should only
affect you if you (a) deploy your Synapse instance from a git checkout or a
github snapshot URL, and (b) have email notifications enabled.

If you have email notifications enabled, you should ensure that
`email.template_dir` is either configured to point at a directory where you
have installed customised templates, or leave it unset to use the default
templates.

The configuration parser will try to detect the situation where
`email.template_dir` is incorrectly set to `res/templates` and do the right
thing, but will warn about this.

Features
--------

- Ship the example email templates as part of the package ([\#4052](#4052))
- Add support for end-to-end key backup (MSC1687) ([\#4019](#4019))

Bugfixes
--------

- Fix bug which made get_missing_events return too few events ([\#4045](#4045))
- Fix bug in event persistence logic which caused 'NoneType is not iterable' ([\#3995](#3995))
- Fix exception in background metrics collection ([\#3996](#3996))
- Fix exception handling in fetching remote profiles ([\#3997](#3997))
- Fix handling of rejected threepid invites ([\#3999](#3999))
- Workers now start on Python 3. ([\#4027](#4027))
- Synapse now starts on Python 3.7. ([\#4033](#4033))

Internal Changes
----------------

- Log exceptions in looping calls ([\#4008](#4008))
- Optimisation for serving federation requests ([\#4017](#4017))
- Add metric to count number of non-empty sync responses ([\#4022](#4022))
@erikjohnston erikjohnston deleted the erikj/log_looping_exceptions branch December 12, 2018 15:45
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants