Introduce `Clock.add_system_event_trigger(...)` to wrap system event callback code in a logcontext, ensuring we can identify which server generated the logs. Background: > Ideally, nothing from the Synapse homeserver would be logged against the `sentinel` > logcontext as we want to know which server the logs came from. In practice, this is not > always the case yet especially outside of request handling. > > Global things outside of Synapse (e.g. Twisted reactor code) should run in the > `sentinel` logcontext. It's only when it calls into application code that a logcontext > gets activated. This means the reactor should be started in the `sentinel` logcontext, > and any time an awaitable yields control back to the reactor, it should reset the > logcontext to be the `sentinel` logcontext. This is important to avoid leaking the > current logcontext to the reactor (which would then get picked up and associated with > the next thing the reactor does). > > *-- `docs/log_contexts.md` Also adds a lint to prefer `Clock.add_system_event_trigger(...)` over `reactor.addSystemEventTrigger(...)` Part of https://github.com/element-hq/synapse/issues/18905 |
||
|---|---|---|
| .. | ||
| build_debian_packages.py | ||
| check_line_terminators.sh | ||
| check_locked_deps_have_sdists.py | ||
| check_pydantic_models.py | ||
| check_schema_delta.py | ||
| check-newsfragment.sh | ||
| complement.sh | ||
| config-lint.sh | ||
| database-save.sh | ||
| docker_update_debian_changelog.sh | ||
| dump_macaroon.py | ||
| federation_client.py | ||
| gen_config_documentation.py | ||
| generate_sample_config.sh | ||
| lint.sh | ||
| make_full_schema.sh | ||
| mypy_synapse_plugin.py | ||
| next_github_number.sh | ||
| release.py | ||
| schema_versions.py | ||
| sign_json.py | ||