41 lines
1.6 KiB
Markdown
41 lines
1.6 KiB
Markdown
|
---
|
||
|
|
summary: 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.
|
||
|
|
tags:
|
||
|
|
- type/reference
|
||
|
|
- tool/credvault
|
||
|
|
scope: global
|
||
|
|
date: 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:
|
||
|
|
|
||
|
|
```bash
|
||
|
|
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.)
|
||
|
|
|
||
|
|
## Related
|
||
|
|
|
||
|
|
- [[credvault-locked-status-is-not-blocking]]
|