Closes the two non-blocking review notes on the merged PR #126.
1. The Zulip key requirement was vestigial and misleading
/api/v1/server_settings is a public endpoint (verified HTTP 200 with and without a credential), and it is the only place ZULIP_AUTH was ever used. So the digest demanded a key that did nothing, and then labelled a leg degraded that was not — the reviewer caught the consequence live: the run printed Zulip Ext: ✅ while also printing credential-missing: ZULIP_API_KEY.
Now: no Zulip key is read or required, with a comment recording why, and a standing rule in the code that any future leg genuinely needing abiba-bot's key must prove it with a 200 from /api/v1/users/me as abiba-bot and label itself degraded when it cannot — never falling back to the vault's shared ZULIP_API_KEY (a different credential that 401s as abiba-bot).
2. A failed send now exits non-zero (reviewer finding F2, pre-existing)
With a wrong password the script reached smtp.gmail.com, printed the SMTP refusal and exited 0 — indistinguishable by exit code from a delivered digest. It now exits 1 on a real send failure, while a credential that is simply NOT CONFIGURED keeps exit 0. That distinction is the point of the change.
Evidence (from the author)
no-credential run: exit 0, digest artifact still produced
deliberately wrong password: exit 1 with the labelled SMTP error
grep -n ZULIP_API_KEY: only the explanatory comment remains
1 file changed, +10/-8. No credential placed, moved, read or substituted anywhere.
Related: daily-health-digest-delivery-20260920, daily-digest-mail-transport-20260921 (the email transport itself is blocked on the captain — Google answers 534 Application-specific password required).
cc @abiba
Closes the two non-blocking review notes on the merged PR #126.
## 1. The Zulip key requirement was vestigial and misleading
`/api/v1/server_settings` is a public endpoint (verified HTTP 200 with and without a credential), and it is the _only_ place `ZULIP_AUTH` was ever used. So the digest demanded a key that did nothing, and then labelled a leg degraded that was not — the reviewer caught the consequence live: the run printed `Zulip Ext: ✅` while also printing `credential-missing: ZULIP_API_KEY`.
Now: no Zulip key is read or required, with a comment recording why, and a standing rule in the code that any future leg genuinely needing abiba-bot's key must prove it with a 200 from `/api/v1/users/me` as abiba-bot and label itself degraded when it cannot — never falling back to the vault's shared `ZULIP_API_KEY` (a different credential that 401s as abiba-bot).
## 2. A failed send now exits non-zero (reviewer finding F2, pre-existing)
With a wrong password the script reached smtp.gmail.com, printed the SMTP refusal and exited 0 — indistinguishable by exit code from a delivered digest. It now exits 1 on a real send failure, while a credential that is simply NOT CONFIGURED keeps exit 0. That distinction is the point of the change.
## Evidence (from the author)
- no-credential run: exit 0, digest artifact still produced
- deliberately wrong password: exit 1 with the labelled SMTP error
- `grep -n ZULIP_API_KEY`: only the explanatory comment remains
1 file changed, +10/-8. No credential placed, moved, read or substituted anywhere.
Related: daily-health-digest-delivery-20260920, daily-digest-mail-transport-20260921 (the email transport itself is blocked on the captain — Google answers 534 `Application-specific password required`).
cc @abiba
1. Remove vestigial ZULIP_API_KEY requirement:
- /api/v1/server_settings is a PUBLIC endpoint (verified HTTP 200 with or without credential)
- No Zulip API key is required for this call
- If a future leg genuinely needs abiba-bot's key, it must prove it with a 200 from
/api/v1/users/me as abiba-bot and label itself degraded when it cannot
- Never fall back to the vault's shared ZULIP_API_KEY
2. Make failed sends exit non-zero:
- A degraded leg (no credential configured) must stay exit 0
- A failed send (attempted and failed) must exit 1
- This distinguishes 'not configured' from 'attempted and failed'
Test evidence:
- No-credential run: exit 0, digest still produced
- Wrong password: exit 1, labelled SMTP error
- grep -n ZULIP_API_KEY: only comment reference remains
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes the two non-blocking review notes on the merged PR #126.
1. The Zulip key requirement was vestigial and misleading
/api/v1/server_settingsis a public endpoint (verified HTTP 200 with and without a credential), and it is the only placeZULIP_AUTHwas ever used. So the digest demanded a key that did nothing, and then labelled a leg degraded that was not — the reviewer caught the consequence live: the run printedZulip Ext: ✅while also printingcredential-missing: ZULIP_API_KEY.Now: no Zulip key is read or required, with a comment recording why, and a standing rule in the code that any future leg genuinely needing abiba-bot's key must prove it with a 200 from
/api/v1/users/meas abiba-bot and label itself degraded when it cannot — never falling back to the vault's sharedZULIP_API_KEY(a different credential that 401s as abiba-bot).2. A failed send now exits non-zero (reviewer finding F2, pre-existing)
With a wrong password the script reached smtp.gmail.com, printed the SMTP refusal and exited 0 — indistinguishable by exit code from a delivered digest. It now exits 1 on a real send failure, while a credential that is simply NOT CONFIGURED keeps exit 0. That distinction is the point of the change.
Evidence (from the author)
grep -n ZULIP_API_KEY: only the explanatory comment remains1 file changed, +10/-8. No credential placed, moved, read or substituted anywhere.
Related: daily-health-digest-delivery-20260920, daily-digest-mail-transport-20260921 (the email transport itself is blocked on the captain — Google answers 534
Application-specific password required).cc @abiba
1. Remove vestigial ZULIP_API_KEY requirement: - /api/v1/server_settings is a PUBLIC endpoint (verified HTTP 200 with or without credential) - No Zulip API key is required for this call - If a future leg genuinely needs abiba-bot's key, it must prove it with a 200 from /api/v1/users/me as abiba-bot and label itself degraded when it cannot - Never fall back to the vault's shared ZULIP_API_KEY 2. Make failed sends exit non-zero: - A degraded leg (no credential configured) must stay exit 0 - A failed send (attempted and failed) must exit 1 - This distinguishes 'not configured' from 'attempted and failed' Test evidence: - No-credential run: exit 0, digest still produced - Wrong password: exit 1, labelled SMTP error - grep -n ZULIP_API_KEY: only comment reference remains