pastilhas
78896793aa
The agent inferred auto-pull.sh had pulled alpha and fofos ahead of the rollout. It had not. alpha was rolled by hand by the session that cut the release, before being stopped; fofos was current because it had been deployed to all day for plugin work. The wrong reading is kept in the text rather than deleted — a real cron, on the right machine, with the right effect, and nothing to do with this. That is what a plausible wrong answer looks like.
72 lines
5.2 KiB
Markdown
72 lines
5.2 KiB
Markdown
# 2026.09.09.01 — report
|
|
|
|
**4 of 4 target hosts succeeded.** `officer-dev` skipped entirely, as the host the rollout ran on.
|
|
`macbruno` and both Pertento hosts skipped per the plan and `docs/servers.md`.
|
|
|
|
Every target ended at `be3139f9` — the commit `deploy/2026.09.09.01` points at. `plugin_ports` was
|
|
verified **by query on each host's own database**, not inferred from `db:push` exit codes.
|
|
|
|
**Two hosts were already at the tag before the rollout touched them, and the cause was a person, not a
|
|
process.** `alpha` was at `be3139f9` rather than the `19bbbab9` the plan recorded, and `fofos` was at
|
|
`be3139f9`. The deploy agent inferred `auto-pull.sh` on its minute crontab; **that inference is wrong
|
|
and is corrected here** so nobody spends time hunting a mechanism that was not involved.
|
|
|
|
What actually happened: the session that cut this release also rolled `alpha` by hand before being
|
|
stopped — the release is the releaser's job and the rollout is this commander's, and that line was
|
|
crossed. `fofos` was at `master` for an unrelated reason: it had been deployed to repeatedly through
|
|
the day during work on the `fofos-website` plugin.
|
|
|
|
So their merges were no-ops. Only `macbookpro` and `deadpool-rezio-bridge` were genuine fast-forwards,
|
|
and they are also the only two where `bun install` had work to do.
|
|
|
|
The `auto-pull` reading is worth keeping visible rather than deleting, because it is exactly the shape
|
|
of a plausible wrong answer: a real cron, on the right machine, with the right effect, that had nothing
|
|
to do with this. A host being unexpectedly current is evidence of *something*, and "the obvious
|
|
candidate" is not the same as the cause.
|
|
|
|
## Per host
|
|
|
|
| Host | HEAD before → after | `bun install` | `plugins:update` | `plugin_ports` by query | `officer` restart_time | health |
|
|
| --- | --- | --- | --- | --- | --- | --- |
|
|
| `officer-dev` | — | — | — | — | — | **SKIPPED** — the host this ran on |
|
|
| `alpha` | `be3139f9` → `be3139f9` | no changes | **16/17, exit 1** | ✓ present, 5 cols | 10 → 11, online | `401` (9000) |
|
|
| `fofos` | `be3139f9` → `be3139f9` | no changes | **4/5, exit 1** | ✓ present, 5 cols | 380 → 381, online | `401` (9000) |
|
|
| `macbookpro` | `c97da029` → `be3139f9` | **+ @anthropic-ai/sdk@0.71.2** | no plugins installed | ✓ present, 5 cols | 0 → 1, online | `401` (**9010**) |
|
|
| `deadpool-rezio-bridge` | `c97da029` → `be3139f9` | **+ @anthropic-ai/sdk@0.71.2** | 2/2, exit 0 | ✓ present, 5 cols | 0 → 1, online | `401` (9000) |
|
|
|
|
`401` on `/api/health` is healthy — the endpoint is behind auth. Ports were read from each `.env`.
|
|
|
|
The schema check run per host was `select to_regclass('public.plugin_ports')`, answered `plugin_ports`
|
|
on all four, with columns `id`, `app_name`, `name`, `port`, `allocated_at timestamptz`. Databases:
|
|
`officer_dev` on `alpha` and `macbookpro`, `officer` on `fofos` and `deadpool-rezio-bridge`.
|
|
No `db:push` prompted for anything — `< /dev/null` was used on every host, as the plan required.
|
|
|
|
## What the owner should act on
|
|
|
|
- **`plugins:update` failed on two hosts, both for uncommitted work in a plugin checkout.** Nothing was
|
|
discarded. Each is one `git commit` or `git checkout --` away from clean:
|
|
- `alpha` — `plugins/av-club` at `62972c1`, 3 modified: `docs/SECURITY.md`, `sidecar/config.ts`,
|
|
`sidecar/paths.ts`. That plugin did **not** update on `alpha` and is still on its old checkout.
|
|
- `fofos` — `plugins/fofos-website` at `7001eb0`, 1 modified: `frontend/Layout/Footer/Footer.tsx`.
|
|
Same consequence: that plugin did not update.
|
|
- **`alpha` could not fetch.** `git fetch origin --tags` failed with
|
|
`Connection closed by 77.42.39.155 port 22` — gitea's public SSH, rate-limited at the proxy. Its
|
|
`origin` is `git@gitea.officer.dev`. It made no difference this time because the tag was already
|
|
local, but a host that genuinely needed the tag would have failed there. **The remote on that host is
|
|
the thing that is wrong**; pointing it at the tailnet address removes the whole class. The same
|
|
recommendation was made in the `2026.08.30.03` report about `macbookpro`, which fetched cleanly today.
|
|
- **`macbruno` was not attempted.** The plan recorded it unreachable at cut time (`Connection timed
|
|
out`, 2026-09-09) and named it skipped, so no retry budget was spent on it. It is at `c97da029` as far
|
|
as anyone knows and will be a real fast-forward whenever it is next reached.
|
|
- **`officer-dev` still wants the marketplace column.** `plugins.release_tag` in `marketplace_db` is
|
|
out of scope for this rollout by the plan's own words — `bun db:push` covers `officer_db` only, and
|
|
`officer-marketplace` runs on this host alone, which is the host the rollout skips. Whoever restarts
|
|
`officer-dev` deliberately should apply it then. Nothing improvised a second push to reach it.
|
|
|
|
## Not done, deliberately
|
|
|
|
- `officer-dev` — not pulled, not restarted, nothing touched. It is already at `be3139f9` in code.
|
|
- `macbruno`, `production-pertento-bridge`, `edge-pertento-bridge` — skipped, no fault on any of them.
|
|
- The `bunx tsgo` error at `src/servers/sidecar/claude/claude-manager.ts:667` was neither checked nor
|
|
fixed. The plan names it as pre-existing and type-only; nothing in this rollout would have surfaced it.
|