Files
synapse/docs
Erik JohnstonandClaude Fable 5 c7d3246550 Attribute Rust-spawned work to the caller's logcontext
Give tokio tasks a captured logcontext, resolving the module-doc TODO:

- LogContextHandle is a cheap, clone-able, GIL-free handle in the same
  Option<Py<LoggingContext>> representation the storage slots use.
  create_deferred captures the caller's context at the FFI boundary and
  scopes it onto the spawned task via a tokio task-local, which rides with
  the task across .await points. current_context() gives the task-local
  read precedence, so log records emitted while a task is polled — via
  LoggingContextFilter and pyo3-log — are attributed to the captured
  context with no per-record stamping.

- The switch primitive is only ever driven on reactor/threadpool threads,
  never during a tokio-scoped poll (where the write would be invisible to
  reads); swap_current_context enforces that invariant with an error log
  rather than trusting it.

- run_python_awaitable restores the captured context on the reactor
  thread before driving the awaitable, so Python called back from Rust
  (e.g. DatabasePool.runInteraction from the Rust /versions handler) runs
  in — and accounts its DB usage against — the right request. The restore
  protocol lives in a new with_logcontext helper (the Rust equivalent of
  `with PreserveLoggingContext(...)`): an error cannot skip the restore
  (which would leak the context onto the reactor thread permanently), and
  a context that has already finished is not re-started (create_deferred
  does not propagate cancellation, so a task can outlive its request; see
  the TODO) — such work runs in the sentinel instead.

- tests/synapse_rust/test_logcontext.py exercises both guarantees through
  real production code paths: reqwest's log records carry the caller's
  request id, and the /versions handler's DB transaction lands on the
  caller's usage accounting.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JFbRtswu7rsHrttJFauUUb
2026-07-17 15:14:34 +00:00
..
2024-02-06 09:26:55 +00:00
2023-12-13 16:37:10 +00:00
2023-12-13 16:15:22 +00:00
2025-05-20 13:31:05 +00:00
2023-12-13 16:15:22 +00:00
2023-12-13 16:37:10 +00:00

Synapse Documentation

The documentation is currently hosted here. Please update any links to point to the new website instead.

About

This directory currently holds a series of markdown files documenting how to install, use and develop Synapse. The documentation is readable directly from this repository, but it is recommended to instead browse through the website for easier discoverability.

Adding to the documentation

Most of the documentation currently exists as top-level files, as when organising them into a structured website, these files were kept in place so that existing links would not break. The rest of the documentation is stored in folders, such as setup, usage, and development etc. All new documentation files should be placed in structured folders. For example:

To create a new user-facing documentation page about a new Single Sign-On protocol named "MyCoolProtocol", one should create a new file with a relevant name, such as "my_cool_protocol.md". This file might fit into the documentation structure at:

  • Usage
    • Configuration
      • User Authentication
        • Single Sign-On
          • My Cool Protocol

Given that, one would place the new file under usage/configuration/user_authentication/single_sign_on/my_cool_protocol.md.

Note that the structure of the documentation (and thus the left sidebar on the website) is determined by the list in SUMMARY.md. The final thing to do when adding a new page is to add a new line linking to the new documentation file:

- [My Cool Protocol](usage/configuration/user_authentication/single_sign_on/my_cool_protocol.md)

Building the documentation

The documentation is built with mdbook, and the outline of the documentation is determined by the structure of SUMMARY.md.

First, get mdbook. Then, from the root of the repository, build the documentation with:

mdbook build

The rendered contents will be outputted to a new book/ directory at the root of the repository. Please note that index.html is not built by default, it is created by copying over the file welcome_and_overview.html to index.html during deployment. Thus, when running mdbook serve locally the book will initially show a 404 in place of the index due to the above. Do not be alarmed!

You can also have mdbook host the docs on a local webserver with hot-reload functionality via:

mdbook serve

The URL at which the docs can be viewed at will be logged.

Synapse configuration documentation

The Configuration Manual page is generated from a YAML file, schema/synapse-config.schema.yaml. To add new options or modify existing ones, first edit that file, then run scripts-dev/gen_config_documentation.py to generate an updated Configuration Manual markdown file.

Build the book as described above to preview it in a web browser.

Configuration and theming

The look and behaviour of the website is configured by the book.toml file at the root of the repository. See mdbook's documentation on configuration for available options.

The site can be themed and additionally extended with extra UI and features. See website_files/README.md for details.