Skip to content

fix: harden the curator loop and how bots reach their Matrix client - #63

Merged
arthware-dev merged 3 commits into
mainfrom
fix/type-checker-findings
Aug 4, 2026
Merged

fix: harden the curator loop and how bots reach their Matrix client#63
arthware-dev merged 3 commits into
mainfrom
fix/type-checker-findings

Conversation

@arthware-dev

Copy link
Copy Markdown
Contributor

The first findings from the type checker landing in #62, in three commits.

  • curator: a wedged rebuild is killed and one that cannot start is reported, rather than escaping into a while True that has no exception handling of its own. Two tests pin that contract.
  • bindings: stck, edits, doc_type were each read under a branch that only assigned them under an earlier one. Safe today, one edit from a NameError.
  • bots: everything after start() reached the Matrix client through an optional _client, so 39 uses read as "might be None". A client property states the precondition once. Teardown and the paths that degrade without a connection still check _client themselves.

Takes the tree from 183 to 145, with microbot.py going 38 -> 4.

A rebuild that wedges is killed, and a child that cannot start at all is
reported instead of taking the sidecar's loop down with it. Pins both in
tests, since the loop calling it has no exception handling of its own.
Each of these read a variable that is only assigned under an earlier
branch. Safe today because the same flag guards both ends, one edit away
from a NameError. No behaviour change.
Everything after start() went through an optional _client, so each of
the 39 uses read as "might be None". A connected() property states the
precondition once: use it and a mistake reports itself, instead of an
AttributeError on None further downstream. Teardown and the paths that
degrade without a connection still check _client themselves.
@arthware-dev

Copy link
Copy Markdown
Contributor Author

Reviewer note on the curator commit: both of its tests pass against the old code too. The old ordering was safe by accident, because the timeout always came from the wait_for on the line after the one that binds proc, so proc.kill() was never actually reached unbound. The tests pin the contract the loop depends on, which was untested either way; they do not demonstrate a fix, because there was no reachable failure to demonstrate.

Verified on this branch: basedpyright 145 (from 183), ruff clean, 2316 passed / 8 skipped.

@arthware-dev
arthware-dev merged commit faa5fdc into main Aug 4, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant