Skip to content

Add bounded Linux credential worker foundation - #723

Open
enaboapps wants to merge 2 commits into
linux-supportfrom
feat/722-linux-credential-worker
Open

enaboapps wants to merge 2 commits into
linux-supportfrom
feat/722-linux-credential-worker

Conversation

@enaboapps

@enaboapps enaboapps commented Sep 11, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Closes #722. Depends on #721; intentionally targets linux-support per the integration-branch workflow. Incremental worker commit: 0614c5b (parent db48185).

Adds one blocking credential worker with single-operation admission, bounded async waits, cancellation generations, stale-result suppression and fixed errors. Validates request/response bounds and documents non-cancellable native writes and stuck-worker recovery. Not connected to the unavailable Linux runtime: no Bluetooth, pairing or input activation.

Validation

  • npm run lint, npm test (114 frontend + 5 updater tests), npm run build: passed.
  • cargo fmt --check and git diff --check: passed.
  • Four fake-store worker tests and Clippy passed in an isolated harness importing the actual worker source with a storage stub; 100 repeated test runs also passed.
  • Full local native cargo test/Clippy blocked by missing GTK/GLib development libraries.
  • Linux CI passed full Clippy, 219 application unit tests (including all four worker tests), 7 integration tests, probe checks and development app build.
  • All CI checks passed at reviewed head: Linux (5m12s), macOS (10m54s), Windows (17m43s), frontend, dependency audit and CodeQL. CI run 34626932791; CodeQL run 34626932775.
  • Independent review of latest head 0614c5b found no actionable issues; reviewer also passed fake tests and strict Clippy.

Remaining gates

Production runtime ownership/startup migration, real Secret Service qualification and Bluetooth subscriber isolation are not implemented or claimed here. No hardware/keyring state was modified.

@enaboapps
enaboapps marked this pull request as ready for review September 11, 2026 17:37
@greptile-apps

greptile-apps Bot commented Sep 11, 2026

Copy link
Copy Markdown

Greptile Summary

Summary

  • The credential worker can deliver a backend result after the application invalidates an already-admitted request.
  • The cancellation ordering in src-tauri/src/linux_credential_worker.rs must be corrected before merging, because callers can act on work that should have been cancelled.

Confidence Score: 4/5

Not safe to merge until cancellation consistently invalidates requests that were already admitted.

A reproduced correctness failure allows an invalidated credential operation to return its backend result.

Files Needing Attention: src-tauri/src/linux_credential_worker.rs

T-Rex T-Rex Logs

What T-Rex did

  • T-Rex produced a proof for a posted P1 finding and linked it to the corresponding review comment.
  • A focused contract-validation harness was executed to force invalidation between admission and snapshot capture, yielding mode=before Ok and a Cancelled result in the after comparison.
  • T-Rex produced a second proof for a posted P1 finding and linked it to the corresponding review comment.

View all artifacts

T-Rex Ran code and verified through T-Rex

Prompt To Fix All With AI
### Issue 1
src-tauri/src/linux_credential_worker.rs:175
**Preserve invalidation ordering**

The request marks the worker busy before it snapshots the cancellation generation. If `invalidate()` runs in that interval, the request records the new generation, so both later generation checks succeed and its backend result is delivered even though the request was already admitted when cancellation occurred. Capture the generation before admission, or make admission and generation capture atomic with respect to invalidation, so cancelled credential work cannot be applied.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Reviews (1): Last reviewed commit: "Add bounded Linux credential worker foun..." | Re-trigger Greptile

{
return Err(WorkerError::Busy);
}
let generation = self.state.generation.load(Ordering::SeqCst);

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Preserve invalidation ordering

The request marks the worker busy before it snapshots the cancellation generation. If invalidate() runs in that interval, the request records the new generation, so both later generation checks succeed and its backend result is delivered even though the request was already admitted when cancellation occurred. Capture the generation before admission, or make admission and generation capture atomic with respect to invalidation, so cancelled credential work cannot be applied.

Artifacts

Evidence from the check

  • Evidence file captured while the check ran.

Command output from the check

  • The full command output behind this check.

Command output from the check

  • The full command output behind this check.

View artifacts

T-Rex Ran code and verified through T-Rex

Prompt To Fix With AI
This is a comment left during a code review.
Path: src-tauri/src/linux_credential_worker.rs
Line: 175

Comment:
**Preserve invalidation ordering**

The request marks the worker busy before it snapshots the cancellation generation. If `invalidate()` runs in that interval, the request records the new generation, so both later generation checks succeed and its backend result is delivered even though the request was already admitted when cancellation occurred. Capture the generation before admission, or make admission and generation capture atomic with respect to invalidation, so cancelled credential work cannot be applied.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant