[pre-commit.ci] pre-commit autoupdate

.pre-commit-config.yaml

@@ -17,7 +17,7 @@ repos:
   - id: check-yaml
 
 - repo: https://github.com/astral-sh/ruff-pre-commit
-  rev: v0.15.9
+  rev: v0.17.4
   hooks:
     - id: ruff
       args: [--fix, --exit-non-zero-on-fix, --show-fixes]
@@ -32,7 +32,7 @@ repos:
 
 # Type checking
 - repo: https://github.com/pre-commit/mirrors-mypy
-  rev: v1.20.0
+  rev: v2.4.1
   hooks:
   - id: mypy
     files: 'src/.*\.py$'

README.rst

@@ -39,4 +39,4 @@ To achieve more complex workflows services can be interconnected using
 `recipes`_ whereby the output of one service can be directed
 onwards to other services.
 
-.. _recipes: https://github.com/DiamondLightSource/python-workflows/tree/main/src/workflows/recipe/README.MD
+.. _recipes: https://github.com/DiamondLightSource/python-workflows/tree/main/src/workflows/recipe/README.md

src/workflows/recipe/README.MD → src/workflows/recipe/README.md

@@ -1,6 +1,6 @@
 ## Recipes
 
-A [service](../services/README.MD) listens on a [channel](../transport/README.MD), acts on incoming messages, and produces some output.
+A [service](../services/README.md) listens on a [channel](../transport/README.md), acts on incoming messages, and produces some output.
 The place where this output is sent to could be hardcoded, ie. written into the source code of the service.
 This makes the service structure rigid, and connecting one service to the output of another requires coordinating the source code of both services.
 Naturally, this approach does not scale well.

src/workflows/transport/common_transport.py

@@ -24,7 +24,7 @@ class CommonTransport:
     Contains e.g. the logic to manage subscriptions and transactions.
     """
 
-    __callback_interceptor = None
+    __callback_interceptor: Callable[[MessageCallback], MessageCallback] | None = None
     __subscriptions: dict[int, dict[str, Any]] = {}
     __subscription_id: int = 0
     __transactions: set[int] = set()