fix(bundle): distinguish RETRY exits (code 2) from OK exits (code 0)

[fuleinist]

Summary

Bundle runner's close handler treated any exit code 0 as ok:true, but the RETRY path in _seed-utils.mjs (contract mode: declareRecords returned 0 with zeroIsValid=false) also called process.exit(0). This made graceful-failure seeder exits appear identical to successful runs in bundle logs — status=OK with records= and no seedComplete marker.

Problem

When a contract-mode seeder hits the RETRY path:

1. Seeder logs RETRY: declareRecords returned 0 — envelope unchanged, TTL extended, bundle will retry next cycle
2. Seeder exits with code 0
3. Bundle runner's close handler sees code === 0 → ok: true
4. Bundle summary shows status=OK records= durationMs=… — indistinguishable from a real success

Real upstream outages are masked; bundle health monitoring cannot detect when a seeder is failing gracefully.

Solution

_seed-utils.mjs (RETRY path)

Changed process.exit(0) → process.exit(2). Exit code 2 is otherwise unused (code 1 = hard failure, code 143 = SIGTERM).

_bundle-runner.mjs (close handler)

Added explicit handling for code 2:

} else if (code === 2) {
  // Exit code 2 = RETRY (graceful failure in contract mode). Do not
  // treat as ok, but do not alert as a hard failure either — TTL was
  // already extended by the seeder and bundle will retry next cycle.
  settle({ elapsed, ok: false, reason: 'graceful_retry', alreadyLogged: false });
}

The bundle summary will now show these sections as ok:false reason=graceful_retry, clearly distinct from both successful runs and hard failures.

Testing

New test file: tests/bundle-runner-exit-codes.test.mjs

• RETRY path exits with code 2: verifies _seed-utils.mjs RETRY block calls process.exit(2) (not 0)
• Hard failure exits with code 1: verifies strictFailure path exits non-zero
• code 0 → ok:true, seedComplete set: bundle runner behavior
• code 2 → ok:false, reason:graceful_retry: bundle runner behavior for RETRY
• code 1 / null / signal → ok:false: error path coverage
• seed_complete JSON event: verifies logSeedResult in _seed-utils.mjs emits correct event

All 9 tests pass.

Files Changed

• scripts/_seed-utils.mjs — RETRY path: process.exit(0) → process.exit(2)
• scripts/_bundle-runner.mjs — close handler: explicit code 2 branch
• tests/bundle-runner-exit-codes.test.mjs — new test file

Fixes #3526.

[greptile-apps]

Greptile Summary

This PR adds a Linux/DBus keyring fallback to SecretsCache: when keyring::Entry::set_password fails, secrets are persisted as a plaintext JSON file in the app data directory, and load_from_keychain can read them back on the next launch. SecretsCache initialization is moved from the eager .manage() call into .setup() so app.app_data_dir() is available.

Note: The PR title and description describe JavaScript bundle-runner exit-code changes (scripts/_seed-utils.mjs, scripts/_bundle-runner.mjs) that are not present in the diff. The actual changes are entirely in src-tauri/.

• src-tauri/src/main.rs — Adds app_data_dir: PathBuf to SecretsCache, a file-read path in load_from_keychain, and a file-write fallback in save_vault when the keyring is unavailable.
• src-tauri/Cargo.toml — Package version rolled back from 2.8.0 to 2.6.7 (unexplained).

Confidence Score: 3/5

The fallback write path can fail on a fresh Linux install before the app data directory exists, and when it does fall back to file storage the secrets are written as unencrypted JSON with no permission hardening.

The save_vault fallback lacks a create_dir_all call, meaning the very first set_secret invocation on a fresh Linux install where the keyring is unavailable will fail with ENOENT and leave the user's secret unsaved. Combined with the already-noted plaintext file exposure, the file-based fallback path needs additional hardening before this is ready to ship.

src-tauri/src/main.rs — specifically the save_vault keyring-fallback branch and the app_data_dir empty-path guard on the write side.

Important Files Changed

Filename	Overview
src-tauri/src/main.rs	Adds Linux/DBus file-based keyring fallback; save_vault fallback path lacks create_dir_all, risking ENOENT on first write to a fresh install; keyring_err is unused (compiler warning); empty app_data_dir guard is present on load but not on write.
src-tauri/Cargo.toml	Version downgraded from 2.8.0 to 2.6.7; no other dependency changes. The downgrade is unexplained in the diff but was flagged in a prior review thread.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[App setup: load_from_keychain] --> B{Keyring entry exists?}
    B -- Yes --> C{JSON valid & non-empty?}
    C -- Yes --> D[Return SecretsCache from keyring]
    C -- No --> E{app_data_dir non-empty?}
    B -- No --> E
    E -- Yes --> F{secrets-vault.json exists?}
    F -- Yes --> G{JSON valid & non-empty?}
    G -- Yes --> H[Return SecretsCache from file]
    G -- No --> I[Migration: read individual keys]
    F -- No --> I
    E -- No --> I
    I --> J[Return SecretsCache from migrated keys]
    K[set_secret / delete_secret] --> L[save_vault]
    L --> M{keyring set_password OK?}
    M -- Yes --> N[Done]
    M -- No --> O{app_data_dir non-empty?}
    O -- Yes --> P{Directory exists on disk?}
    P -- Yes --> Q[Write secrets-vault.json]
    P -- No --> R[ENOENT error - secret not saved]
    O -- No --> S[Write to CWD/secrets-vault.json]

Loading

_{Reviews (1): Last reviewed commit: "fix(desktop): read fallback vault file i..." | Re-trigger Greptile}

[greptile-apps]

Secrets written as plaintext JSON on Linux DBus fallback

When the keyring is unavailable, secrets-vault.json is written as unencrypted JSON in the app data directory. Any process or user account that can read the app data directory can read all stored API keys in cleartext. At minimum, the file's permissions should be restricted to the owner (0o600) immediately after creation; ideally a note should warn callers that this path trades security for compatibility.

[fuleinist]

SECURITY NOTE added to the fallback branch documenting the plaintext exposure risk. File permissions are now set to 0o600 (owner read/write only) on Unix via set_permissions. See fuleinist@15f547f3#diff-fec9337

[greptile-apps]

Unused variable keyring_err will produce a compiler warning

keyring_err is bound but never read. The Rust compiler will emit an unused_variables warning here. Prefixing with _ suppresses the warning and makes the intentional-swallow explicit.

Suggested change

	Err(keyring_err) => {
	// Linux/DBus fallback: write vault to app data dir as plaintext JSON file
	Err(_keyring_err) => {
	// Linux/DBus fallback: write vault to app data dir as plaintext JSON file

[fuleinist]

Fixed — keyring_err is now _keyring_err to silence the unused variable warning. See fuleinist@15f547f3#diff-fec9337

[greptile-apps]

app_data_dir() failure is silently swallowed

map_err(|e| format!(...)).unwrap_or_default() converts the Result into an empty PathBuf and discards the formatted error message entirely — nothing is logged and the app continues. Downstream, load_from_keychain guards reads with if !app_data_dir.as_os_str().is_empty(), but save_vault has no such guard: if data_dir is empty and the keyring is unavailable, vault_path resolves to the bare filename "secrets-vault.json" relative to CWD — writing secrets to an arbitrary directory.

[fuleinist]

Fixed — save_vault now checks if app_data_dir is empty and returns an error instead of writing secrets-vault.json to CWD. See fuleinist@15f547f3#diff-fec9337

[vercel]

@fuleinist is attempting to deploy a commit to the World Monitor Team on Vercel.

A member of the Team first needs to authorize it.