amadan
adoptLoop and configSyncLoop have no boot retry/backoff on registry or store open failure Issue open
Migrated from github.com/carlosframework/platform issue #27, opened 2026-08-03. GitHub issues are closed for this repo; see AGENTS.md, "Work is tracked on amadan, not GitHub".
Still outstanding: adoptLoop and configSyncLoop still return permanently on a boot-time store/key failure, so an S3 or IMDS hiccup silences them until restart.
---
Deferred from the PR #16 review ledger ("worth a shared ticket if it ever bites" — filing it so it has a number).
Both agent loops do a first pass ~1 minute after boot and then settle into their hourly cadence, but their setup failures are terminal for the process lifetime:
- \
configSyncLoop\(internal/host/agent.go): if \openDeployStore\or key parsing fails at boot, the loop logs "disabled" once and returns — a transient S3/IMDS hiccup at boot silences config delivery until the next agent restart. - \
adoptLoop\/ \canaryAdoptLoop\: same shape for their store/pubkey setup.
If a box ever boots faster than its network (cloud-init races, IMDS not ready), the agent runs but the loops are permanently dark, with one log line an hour of nothing to hint at it.
Possible fix: a shared retry-with-backoff helper for loop setup (retry the store/key acquisition for a bounded window before declaring disabled), or simply re-attempt setup on each tick instead of once at boot.
Related: PR #16 (deferred-minors comment), #17.