The test fabricated `acct-1` as the watch's account id, but `put`
assigns its own, so the dispatch refused with "names account acct-1,
which is gone" — the test proved nothing about the path it covered.
Capture the assigned id instead.
`(secret.kind == SecretKind::Token).then(|| WatchCredential { .. })`
constructs a value with no work, so clippy's unnecessary_lazy_evaluations
failed `checks`; `then_some` says the same thing.
`watch_forge` looked the dispatch key up in the `watches` table and
nothing else, so a thread that arrived through an *account* watch — the
daemon's own account notifications, which cover the whole instance, not
one repo — failed with "no watch configured" unless the same repo also
had a repo watch row. The dispatch is created by the account poll; the
client it needs is the account's. Nothing could hand it over, because the
payload did not name the account either.
The triaged payload now carries `account_id`, the dispatch drains the
inbox *before* resolving the client (the inbox is where that id lands),
and `watch_forge_as` falls back to the account watch that delivered the
news: its host, its credential, its login. A repo watch row still wins
when there is one — a thread with its own watch keeps its own identity —
and `watch_forge` keeps its signature for callers that know nothing about
accounts, falling back to the kind's first account watch.
The client cache is now one helper over `(forge, host, credential)`, so
the dispatch's replies ride the same pool the poll built.
A watch whose poll fails was invisible: `detect` turned the failure into
one `eprintln!` per tick and nothing else. A watch that had 401'd every
sixty seconds since the day it was created was indistinguishable — on
`/v1/watches`, in the agent's own `list_watches`, everywhere — from a
repository that had simply been quiet. That is how a dead credential
survives for weeks: the log line scrolls, and nothing else remembers.
`watch_health` is a third table beside `watches` and `account_watches`,
keyed by `(scope, forge, subject)`, holding `last_ok_at`, `last_error`,
`last_error_at` and `consecutive_failures`. Every detect pass records
each poll's outcome — repo watches as `repo`, account watches as
`account` — and the pass that *starts* a streak (the first failure after
a success, or after never having succeeded) pushes one device
notification, naming the watch and quoting the forge's error. The rest of
the streak stays quiet: the row carries the count, so the tick's log line
no longer has to.
Readable where the question gets asked: `/v1/watches` answers a `health`
array alongside the two watch lists, and the `list_watches` tool reports
`last_ok_at`, `last_error` and `consecutive_failures` per repo, so "is
this watch working?" is answerable without the daemon's stderr. A watch
that has never polled has no row and reports empty health, which is what
it is.
`resolve_watch_token` handed the adapter a bare string, so the client
could only ever try it as a token — and a `secret_kind` is a label the
human typed at `identity_save`, not a fact: a login password saved as a
token resolved as one, 401'd on every poll, and the watch stayed dead
with nothing said.
`resolve_watch_credential` returns the value *and* the login of the
account it came from (`WatchCredential`), the client cache keys on both
(one value sent two ways is two credentials), and the gitea client is
built with `with_login`, so the adapter's 401 retry can reach the
instance's own Basic-auth form.
A row token or the forge's environment variable names no login, so those
tiers resolve exactly as before: `WatchCredential::bare`, `login: None`.
`resolve_watch_token` stays as the token half, for callers with no use
for the login.
A self-hosted Gitea answers 401 to `Authorization: token <password>` and
200 to the same value as `user:password`, and the account store's
`secret_kind` cannot tell the two apart — it is a label the human typed
at `identity_save`, so a login password saved as a token is
indistinguishable from a real PAT until the forge answers.
`GiteaForge` had one auth path: the token header, on every call. A
watch whose credential resolved to a password therefore 401'd on every
poll, forever, while the same secret worked for `git push` over https
(the credential helper sends it as a password). The watch looked quiet
instead of broken.
`GiteaForge::with_login` names the login that owns the secret, and
`send` tries the token header first, then — on a 401 only — the same
value as Basic auth. The retry is cloned before the token header lands,
so the fallback request carries one `Authorization` header and not two.
No login (a pasted watch token names none) or an unclonable body leaves
the 401 to surface exactly as it did before.
The login reaches the client in the next commit; this one is the adapter
half, tested against a mock that refuses the token header and accepts
the Basic one.
Reported from the phone's diag log:
status: crashed: SecurityException: WifiService: Neither user 10519 nor
current process has android.permission.ACCESS_WIFI_STATE.
at android.os.Parcel.createExceptionOrNull
`PhoneSensors.wifiSsid` read `WifiManager.connectionInfo` behind nothing
but the location grant, but WifiService gates every WifiManager call on
ACCESS_WIFI_STATE — and it enforces that by throwing SecurityException,
not by answering null. The permission was never declared, so the read
always threw.
The cost is larger than the missing SSID: the throw travels out of
`readSnapshot` into the worker's catch, which logs "status: crashed" and
returns failure — so one undeclared permission took the battery, network,
DND and location topics down with it, and the fleet's rows went stale
while the app looked healthy.
Two halves, both needed:
- the manifest declares ACCESS_WIFI_STATE (a normal permission: declaring
it is the whole grant, no runtime prompt). An install that predates the
line keeps the grant set it was installed with, so this alone does not
stop the crash on an existing phone;
- `wifiSsid` returns null unless the permission is actually held, and
wraps the read in `runCatching`, so the status report degrades to "no
wifi name" instead of dying whole. The check is a `hasWifiState` beside
the existing `hasLocation`, same idiom.
The phone's notification poll sent `since` unconditionally, and before
the first ack there is no cursor at all, so it went out as `?since=`.
Axum's `Query` hands a present-but-empty parameter through as an empty
string, and `Option<i64>` only forgives a *missing* key, so the whole
poll answered `400 Failed to deserialize query string: since: cannot
parse integer from empty string` and the phone showed an error instead
of an empty queue.
Both ends: the client omits `since` unless it has a positive id to send,
and a `blank_as_none` deserializer makes a blank value mean "not set"
for `NotificationQuery` and `EventStreamQuery` alike — an empty `since`
reads as "from the start" however it got there.
kosmos