1.6 KiB
| summary | tags | scope | date | ||
|---|---|---|---|---|---|
| Two credvault behaviors that surface in bulk/scripted use — intermittent bw-sync failures needing retry with 20s+ backoff, and the trailing newline on get --secret-only that breaks naive hash comparisons. |
|
global | 2026-07-13 |
credvault behaviors under bulk/scripted use
Discovered 2026-07-13 during a 33-key backfill loop (credvault ensure --secret-file per key).
1. Intermittent bitwarden_command_failed ("bw sync failed") under rapid calls
When credvault is invoked many times in quick succession, the underlying bw sync
intermittently fails and the CLI returns bitwarden_command_failed. It is transient:
the same call succeeds on retry. Backoff matters — 8s between retries was not always
enough; 20s+ per retry (up to 5 attempts) cleared every failure.
Rule: any bulk credvault loop must retry specifically on bitwarden_command_failed
with ≥20s backoff, and classify per-key outcomes (created/existing/secret_conflict/
missing-source/failed) rather than aborting the whole run.
2. get --secret-only output ends with a trailing newline
When verifying a stored value against its source by hash, the vault side includes a
trailing \n that a tr -d '\n'-stripped source does not — producing false MISMATCHes.
Normalize both sides first:
credvault get <key> --secret-only | tr -d '\n' | sha256sum
(Values that are genuinely multi-line files, e.g. a service-account JSON stored via
--secret-file, round-trip byte-identical and compare fine without stripping.)