delivery-kid: source pickipedia bot creds from BLUERAILROAD_BOT_* vault keys#91
Merged
jMyles merged 1 commit intoJun 1, 2026
Conversation
…lt keys The pickipedia_client snapshot path in delivery-kid (added in cryptograss#87) has been silently no-op'ing since deploy: PICKIPEDIA_BOT_PASSWORD in the container is empty, _get_site() returns None without logging, and snapshot_diagnostics returns False without logging. No bot writes ever attempted, no log trail to find the gap. Root cause: the playbook references vault keys named `pickipedia_bot_user` and `pickipedia_bot_password` — which were never added to the vault. The defaults of '' kicked in and the env vars landed empty in the container. The vault DOES have the Magent@magent BotPassword — it's stored as `BLUERAILROAD_BOT_USERNAME` / `BLUERAILROAD_BOT_PASSWORD` and used by maybelle's post-audit-to-wiki.py (which writes the Cryptograss:Delivery-kid-audits/{blockheight} pages successfully). Same bot account, just under a different name in the vault. Point delivery-kid at those keys instead. No vault edit needed; this is purely a rename on the consumer side. ## Follow-up worth doing soon The pickipedia_client should log a single line at module/init time if PICKIPEDIA_BOT_PASSWORD is empty, so the silent-no-op pattern doesn't recur the next time we wire a new env var. Tracking separately rather than bundling here.
This was referenced Jun 1, 2026
jMyles
added a commit
that referenced
this pull request
Jun 1, 2026
The pickipedia_client snapshot path silently no-op'd from #87 deploy until today — _get_site() returned None when PICKIPEDIA_BOT_PASSWORD was empty, with no log line to surface the gap. We only found it by deductive reasoning ("the page doesn't exist, the hook should have fired, where would the snapshot have logged about that") rather than by reading a single explicit log entry. Add a logger.warning the first time we hit that branch, gated on a module-level _warned_missing_creds flag so we warn once per process rather than on every snapshot attempt. Future deployments where someone forgets to wire the env var (or the vault key gets renamed, as in #91) will surface in `docker logs pinning-service` immediately. No behavior change for the cred-present path — exactly the same fast-return when _site is cached.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TL;DR
`pickipedia_client.snapshot_diagnostics` has been silently no-op'ing since #87 landed. The bot password env var has been empty in the delivery-kid container the whole time. One-line-each rename fixes it.
How we got here
The diagnostics-panel-on-the-wiki PR (#82) is rendering live state from `/draft-content` happily — that's why everything looked like it was working. But the bot snapshot path was never able to write `ReleaseDraft:{id}/diagnostics` because:
```
docker exec pinning-service printenv PICKIPEDIA_BOT_PASSWORD
→ (empty)
```
And the snapshot code does the right thing when creds are missing:
```python
def _get_site():
user = os.environ.get("PICKIPEDIA_BOT_USER", "Magent@magent")
password = os.environ.get("PICKIPEDIA_BOT_PASSWORD")
if not password:
return None # ← silent
```
No log line, no exception — just `False` returned from `snapshot_diagnostics` and the caller moves on. Functionally invisible until you go looking for a wiki page that never appeared.
Root cause
`delivery-kid/ansible/playbook.yml` referenced vault keys named `pickipedia_bot_user` / `pickipedia_bot_password`. Those keys do not exist in vault.yml. The Jinja defaults of `''` kicked in and the env vars landed empty in the container.
The Magent@magent BotPassword does exist in the vault — under different names: `BLUERAILROAD_BOT_USERNAME` and `BLUERAILROAD_BOT_PASSWORD`, the same keys that `maybelle/scripts/post-audit-to-wiki.py` reads to write the `Cryptograss:Delivery-kid-audits/{blockheight}` pages successfully every audit run. Same bot, same credential, different name in vault.
The change
Two lines:
```diff
```
No vault edit needed. No new secrets generated. Just point the consumer at the keys that already work.
Test plan
Follow-up worth doing soon (not in this PR)
`pickipedia_client.py` should log a single line at module init or first `_get_site()` call when `PICKIPEDIA_BOT_PASSWORD` is empty, so the silent-no-op pattern is visible in logs rather than purely deductive. Filing as a separate issue rather than bundling here.