quiet intentional fallback, or native ordered fallback sources

[kiyoon]

Two Age providers grant different capabilities:

[providers.dvc-readonly]
type = "age"
recipients = ["<admin>", "<readonly-user>", "<readwrite-user>"]

[providers.dvc-readwrite]
type = "age"
recipients = ["<admin>", "<readwrite-user>"]

One profile prefers read/write and falls back to read-only:

# Internal fallback dependency; never expose this name to the child.
[profiles.dvc.secrets.DVC_READONLY_SAS_TOKEN]
provider = "dvc-readonly"
value = "<encrypted>"
default = "fnox-no-dvc-credential"
env = false
if_missing = "ignore"

# This is the only name exposed to DVC.
[profiles.dvc.secrets.AZURE_STORAGE_SAS_TOKEN]
provider = "dvc-readwrite"
value = "<encrypted>"
default = "${DVC_READONLY_SAS_TOKEN}"
if_missing = "ignore"

# This identity cannot decrypt the RW value, so the same profile returns RO.
FNOX_AGE_KEY_FILE=".private/dvc-readonly-age.txt" \
  fnox -P dvc get AZURE_STORAGE_SAS_TOKEN
# 2026-08-27T02:10:26.761189Z  WARN fnox_core::secret_resolver: Falling back to default value for secret 'AZURE_STORAGE_SAS_TOKEN' after provider resolution failed: Age decryption failed: No matching keys found
# 2026-08-27T02:10:26.761818Z  WARN fnox_core::secret_resolver: Falling back to default value for secret 'AZURE_STORAGE_SAS_TOKEN' after provider resolution failed: Age decryption failed: No matching keys found
# ?sv=...&sp=rl&...

# The admin identity can decrypt the preferred RW value.
FNOX_AGE_KEY_FILE=".private/age.txt" \
  fnox -P dvc get AZURE_STORAGE_SAS_TOKEN
# ?sv=...&sp=racwdl&...

The different results are intentional. The read-only identity receives the read-only token; the admin identity receives the read/write token. For the read-only identity, failure to decrypt the preferred value is normal control flow, but fnox prints a warning every time the program runs (twice in this example).

The same pattern applies to OPENAI_API_KEY. Many programs and scripts can use that variable, but unrelated programs should not see it. It may also resolve to a different key for each developer so usage can be monitored, limited, rotated, or revoked independently. An ordered set of permission-scoped candidates could select Jane's key for Jane, John's key for John, and a shared restricted key for CI. Failed candidates are expected; warning for each rejected candidate makes a successful, intended resolution look unhealthy.

Workaround

We can suppress the current warning globally:

RUST_LOG="${RUST_LOG:-warn},fnox_core::secret_resolver=error" fnox -P dvc exec -- dvc pull

This is a dirty workaround. It changes logging for the whole resolver, is easy to omit at a call site, and can hide warnings from unrelated secrets whose fallback was not intended.

Possible solution 1: configurable fallback log filter

Allow fnox.toml to configure fallback logging with the same target-aware directive syntax as RUST_LOG, rather than only accepting a small off/level enum:

[profiles.dvc.secrets.AZURE_STORAGE_SAS_TOKEN]
provider = "dvc-readwrite"
value = "<encrypted-rw>"
default = "${DVC_READONLY_SAS_TOKEN}"
if_missing = "ignore"
fallback_log = "warn,fnox_core::secret_resolver=error"

Possible solution 2: native ordered fallback sources

Represent the intent directly instead of using an internal secret and string interpolation:

[profiles.dvc.secrets.AZURE_STORAGE_SAS_TOKEN]
if_missing = "error"
sources = [
  { provider = "dvc-readwrite", value = "<encrypted-rw>" },
  { provider = "dvc-readonly", value = "<encrypted-ro>" },
  { default = "fnox-no-dvc-credential" },
]

The same schema could express several developer-specific OPENAI_API_KEY candidates followed by a restricted CI key. Only the resolved value should be exported, and failure should never appear in logs. A final failure with if_missing = "error" should remain a visible error.

For Age providers, fnox can often avoid the expected failed decryption entirely. Derive the public recipient for the effective identity, inspect ordered provider candidates, and silently skip a candidate when that recipient is not in the provider's configured recipients list.

[jdx]

Thanks for the detailed example. I traced the current workaround through the resolver and found two concrete issues:

• if_missing = "ignore" did not suppress the warning emitted when a provider failed but its default resolved successfully.
• For a single-secret lookup with an interpolated default, fnox attempted the preferred provider once directly and then a second time while resolving the interpolation closure. That accounts for the duplicate warning in the example.

I opened #771 to fix both behaviors. Successful fallback under the effective ignore policy is now debug-only, and interpolation resolution excludes the already-attempted root secret, so the preferred Age value is tried once. The regression test recreates the permission-scoped read/write-to-read-only Age fallback.

This is deliberately a focused fix for the existing schema. The native ordered sources proposal here is still relevant as a broader follow-up because it would express the intent without an internal secret. The current behavior comes from #549 (interpolated defaults) and #572 (provider-error fallback), which are referenced in the PR.

AI-assisted — Tool: Codex; model: unavailable; version: unavailable.