ctrlrelay 0.8.0__tar.gz → 0.9.0__tar.gz

{ctrlrelay-0.8.0 → ctrlrelay-0.9.0}/CHANGELOG.md

@@ -7,6 +7,157 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.9.0] - 2026-09-07
+
+### Added
+
+- **`transport.telegram.question_ttl_seconds`: unanswered questions now
+  expire.** A `pending_resumes` row deliberately outlives the in-session
+  wait so a late reply can still drive the resume — but nothing ever
+  retired one, so the table only grew. Measured on one deployment: 46
+  questions posted, 4 ever answered, 16 still live and five repos
+  re-asking the same question on consecutive days. An expired row stops
+  being offered as the routing target for an orphan Telegram reply, and
+  a late answer can no longer revive it. Defaults to 172800 (48h),
+  minimum 3600.
+- **New hourly `question_expiry_sweeper` job.** Retires a question early
+  once every issue and PR it cites is closed or merged — the case where
+  someone merged the PR by hand and the question became meaningless
+  rather than merely unanswered. Fails safe in both directions: a
+  question citing nothing is never expired this way, and any probe error
+  leaves the row alone, because re-asking a dead question is recoverable
+  while dropping a live one is not. The TTL pass runs first and needs no
+  network, so a GitHub outage still lets age-based expiry make progress.
+  Probing is capped at 200 numbers per run so one pass cannot outlive its
+  own hourly interval — unbounded, a 2000-row backlog against a slow
+  GitHub would be 8.3h of serialized `gh api` reads. Rows past the cap
+  are examined on the next run, and the TTL pass retires them on age
+  regardless.
+
+- **`transport.telegram.ask_timeout_seconds`: how long a pipeline waits on
+  your Telegram reply.** Was a hard-coded 300s in `SocketTransport.ask`,
+  with no call site overriding it and no way to configure it. Defaults to
+  900s — deliberately short, because a sweep runs its repos sequentially
+  and holds each repo's lock and worktree for the whole wait, and the
+  poller awaits its issue handler inline. This value only buys the
+  in-session fast path; answering later is covered by the pending-resume
+  path below, so raising it to cover an overnight gap would turn a daily
+  sweep into a multi-day one for no benefit.
+
+### Fixed
+
+- **An expired question can no longer be resumed by a stale bridge.**
+  `answer_pending_resume` already refuses to answer an expired row, but
+  that guard only holds while every process runs the same code. The
+  bridge writes the answer and the poller reads it back — separate
+  daemons — so a deploy that restarts one before the other leaves a
+  window where an old bridge stamps `answered_at` on a row the new
+  poller has already expired, and the resume fires against state that
+  moved on. Seen live: the bridge ran three-day-old code for an hour
+  after the poller was upgraded. `list_pending_resumes_to_execute` now
+  filters expired rows too, closing the window from the side that acts
+  on them.
+
+- **A secops repo failure now says what broke.** A sweep that died before
+  the `sessions` INSERT — anything raised by `ensure_bare_repo` or
+  `create_worktree`, both network-bound and both ahead of it — left no
+  trace at all: the DB update is guarded on the insert having happened,
+  and the `except` block had no logging. With an exception whose `str()`
+  is empty the Telegram alert then fell back to its generic summary, so
+  the operator got `Error processing <repo>` and nothing else. The
+  failure is now logged as `secops.repo.failed` regardless of which
+  branch runs, and both `summary` and `error` carry the exception type.
+- **`git` timeouts stringify to something.** `asyncio.wait_for` raises a
+  bare `TimeoutError` whose message is the empty string; it is now
+  re-raised as the same type with the command, timeout, and cwd
+  attached, so it stays useful wherever it surfaces.
+- **Bare clone and fetch get a transfer-sized timeout.** Both inherited
+  the 120s budget meant for local git plumbing, which a multi-gigabyte
+  repo cannot meet on any normal link — a 1.8 GB repo failed its sweep
+  this way every day. Network transfers now use 1800s, matching claude's
+  own `default_timeout_seconds`.
+- **secops no longer looks at PRs outside its two author-filtered queries.**
+  The prompt only ever tells the agent to run `gh pr list` with
+  `--author "app/dependabot"` and `--author "$OPERATOR"` — but a step-5
+  bullet for "PRs from anyone else" implied a wider list existed, so the
+  agent ran its own unfiltered `gh pr list` to populate the category and
+  then signalled BLOCKED on PRs it can never merge. That fired a Telegram
+  question every sweep, forever, and every one timed out unanswered; run
+  summaries reporting "no open PRs at all" were the fingerprint of the
+  out-of-scope query. A third party's PR is now explicitly out of scope:
+  not fetched, not evaluated, not named in the summary. An explicit scope
+  fence forbids broadening the search. Operator-authored code PRs still
+  ASK, because there the answer genuinely decides what happens next.
+- **BLOCKED questions may no longer be padded with already-decided items.**
+  Real questions were bundling a genuine Dependabot decision with a
+  non-actionable tail ("...confirm no action wanted"), burying the part
+  that needed an answer. Decided items belong in the run summary; a repo
+  with nothing to decide now finishes DONE instead of signalling BLOCKED.
+- **Telegram questions now say which repo and session they belong to.** A
+  secops sweep posts one consolidated question per repo back-to-back and
+  the agent's text rarely names its own repo, so the operator saw a run of
+  near-identical "approve #387?" messages with nothing to tell them apart.
+  Worse, the orphan router's "reply again with the session_id included"
+  instruction was impossible to follow — the session_id had never been sent
+  to the operator in the first place. `ASK` now prefixes the question with
+  `[owner/repo]`, the session_id, and (for dev) the issue number.
+- **Replying to one question no longer answers a different one.** When the
+  bridge couldn't match an incoming reply it fell back to FIFO and
+  delivered the answer to the *oldest* outstanding question. Replying to
+  the third question while the first was still open silently answered the
+  first, with nothing shown to the operator. Reply-to now matches strictly;
+  a plain message routes only when exactly one question is outstanding, and
+  otherwise the operator is told to use Telegram's reply and shown what is
+  waiting.
+- **A late reply now resumes the session it was actually aimed at.** The
+  bridge remembers which session each posted question belongs to (bounded
+  to the last 500), so a reply arriving after the ASK timed out resolves
+  its `pending_resumes` row exactly instead of reporting "multiple BLOCKED
+  sessions are unanswered" and asking for a session_id the operator was
+  never given.
+- **An answer given after the pipeline stopped waiting is no longer thrown
+  away.** When `ask()` timed out, the client discarded the request but did
+  not close the socket — a secops sweep reuses one transport across every
+  repo — so the bridge went on treating the question as live. A later
+  reply-to matched that dead entry, and the ANSWER was written into a
+  request nobody was listening for: no log, no notice, nothing. The
+  operator replied exactly as instructed and the answer vanished. The
+  bridge now tracks each question's deadline and drops expired entries
+  before routing, sending the reply down the pending-resume path instead.
+  Expired entries also no longer inflate the "more than one question is
+  waiting" count, which was refusing plain answers to the one real
+  question.
+- **The post-sweep "blocked on `<repo>`" message is answerable.** It is
+  sent as a one-way notice and its Telegram id was never recorded, so
+  replying to the most recent and most prominent message for a repo landed
+  in the ambiguous branch. A `SEND` that names a session is now tracked the
+  same way an `ASK` is.
+- **Operator notices name repos and sessions, not internal ids.** The
+  "still waiting" listing rendered `telegram_msg_id: request_id` — Telegram
+  never shows message ids in its UI and `request_id` means nothing to a
+  human. It now uses the same `[owner/repo] (session: …)` shape as the
+  question header.
+
+## [0.8.1] - 2026-09-04
+
+### Fixed
+
+- **`ctrlrelay ci wait` was unconditionally broken on `gh` releases without
+  `--json` support on `pr checks`** (confirmed on gh 2.45.0, the current
+  Ubuntu 24.04 package — no newer version exists in the distro repos, so
+  this wasn't an "apt upgrade" problem for anyone on that platform).
+  `GitHubCLI.get_pr_checks` shelled out to `gh pr checks --json ...`; on an
+  affected install every single poll failed with `unknown flag: --json`,
+  which `PRVerifier.wait_for_checks` treats as transient and retries —
+  so every `ci wait` call was guaranteed to eat its full timeout and then
+  fail, regardless of the PR's actual state. Reproduced directly and
+  confirmed as the likely cause behind some "session never signaled DONE"
+  reports. Switched to `gh pr view --json statusCheckRollup`, stable since
+  early gh 2.x and always exit-0 regardless of check state, with a new
+  normalizer mapping its two GraphQL shapes (`CheckRun` and the legacy
+  `StatusContext`) into the `{name, state, bucket, link}` shape
+  `PRVerifier` already expects. See #145.
+
 ## [0.8.0] - 2026-09-04
 
 ### Added
@@ -1247,7 +1398,9 @@ pipeline).
   per-phase implementation plans (Phase 0 through Phase 4).
 - `docs/Claude_Code_Project_Guide.md` — project development guide.
 
-[Unreleased]: https://github.com/AInvirion/ctrlrelay/compare/v0.8.0...HEAD
+[Unreleased]: https://github.com/AInvirion/ctrlrelay/compare/v0.9.0...HEAD
+[0.9.0]: https://github.com/AInvirion/ctrlrelay/compare/v0.8.1...v0.9.0
+[0.8.1]: https://github.com/AInvirion/ctrlrelay/compare/v0.8.0...v0.8.1
 [0.8.0]: https://github.com/AInvirion/ctrlrelay/compare/v0.7.0...v0.8.0
 [0.7.0]: https://github.com/AInvirion/ctrlrelay/compare/v0.6.0...v0.7.0
 [0.6.0]: https://github.com/AInvirion/ctrlrelay/compare/v0.5.0...v0.6.0

{ctrlrelay-0.8.0 → ctrlrelay-0.9.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: ctrlrelay
-Version: 0.8.0
+Version: 0.9.0
 Summary: Local-first orchestrator for headless coding agents across multiple GitHub repos
 Project-URL: Homepage, https://github.com/AInvirion/ctrlrelay
 Project-URL: Documentation, https://ainvirion.github.io/ctrlrelay/

{ctrlrelay-0.8.0 → ctrlrelay-0.9.0}/config/orchestrator.yaml.example

@@ -37,6 +37,13 @@ transport:
     bot_token_env: "CTRLRELAY_TELEGRAM_TOKEN"
     chat_id: 123456789
     socket_path: "~/.ctrlrelay/ctrlrelay.sock"
+    # Seconds a pipeline waits on your reply before giving up and
+    # persisting the session as BLOCKED. This is only the in-session fast
+    # path — a reply that arrives later still attaches to the saved
+    # session and the pending-resume sweeper drives it. Don't raise this
+    # to cover being asleep: a sweep runs its repos one at a time and
+    # holds each repo's lock and worktree for the whole wait.
+    ask_timeout_seconds: 900
   file_mock:
     inbox: "~/.ctrlrelay/inbox.txt"
     outbox: "~/.ctrlrelay/outbox.txt"

{ctrlrelay-0.8.0 → ctrlrelay-0.9.0}/docs/configuration.md

@@ -118,6 +118,8 @@ transport:
 | `bot_token_env` | string | `"CTRLRELAY_TELEGRAM_TOKEN"` | Name of the environment variable holding the bot token. ctrlrelay never reads the token directly — only the variable name. |
 | `chat_id` | int | `0` | Telegram chat ID the bridge sends messages to and accepts replies from. |
 | `socket_path` | path | `"~/.ctrlrelay/ctrlrelay.sock"` | Unix socket path the bridge listens on. Pipelines connect to this socket as clients. |
+| `ask_timeout_seconds` | int | `900` | How long a pipeline blocks waiting on your reply in-session. Minimum `60`. A reply arriving later still works: the question is persisted to `pending_resumes` and the every-minute sweeper drives the resume. |
+| `question_ttl_seconds` | int | `172800` (48h) | How long an **unanswered** question stays routable before it is retired. Minimum `3600`. Without a ceiling those rows never die — a question whose PR was merged by hand weeks ago stays a live target for an orphan reply. The hourly `question_expiry_sweeper` also retires a question early once every issue/PR it cites is closed or merged. |
 
 See [Telegram bridge]({{ '/bridge/' | relative_url }}) for the full setup walkthrough.
 

{ctrlrelay-0.8.0 → ctrlrelay-0.9.0}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "ctrlrelay"
-version = "0.8.0"
+version = "0.9.0"
 description = "Local-first orchestrator for headless coding agents across multiple GitHub repos"
 readme = "README.md"
 requires-python = ">=3.12"