Cancel and the TTL sweep end an approval without revoking it or writing an event

[vladimirrott]

revoke_unconsumed_approval ends an unspent approval properly: it deletes the row from transaction_approvals and appends ApprovalRevoked in the same database transaction (crates/sysknife-daemon/src/transactions.rs:607). One caller uses it, the undelivered-response path in handle_approve (crates/sysknife-daemon/src/dispatcher.rs:1426).

The two paths an operator reaches do neither:

• cancel_queued flips status to Canceled in one UPDATE (transactions.rs:738), which is what handle_cancel calls (dispatcher.rs:1556).
• cleanup_stale_queued cancels every queued row past the 15-minute TTL in one UPDATE (transactions.rs:715), on a 300-second ticker started at crates/sysknife-daemon/src/main.rs:133.

Neither touches transaction_approvals, and neither appends an event. Postgres matches: crates/sysknife-daemon/src/store/postgres.rs:725 and :707.

Approve a transaction and then cancel it, and the event chain holds approval_granted with no terminal event, while the row stays in transaction_approvals with consumed_at IS NULL for good. docs/the-audit-chain.md:222 sets the expectation those events exist to meet:

The transaction chain records what the daemon authorized. It says nothing about whether a human then approved it, whether that approval was spent, or whether it was retracted.

A reader of the verified chain cannot separate "granted, still valid, the operator is deciding" from "granted, then cancelled". The two look identical.

The sweep hits approved transactions too. Its comment at main.rs:128 says it "only touches expired Queued rows (never Running/Approved)", and there is no Approved state in JobState (crates/sysknife-types/src/lib.rs:503): approval writes a row in a separate table and leaves status at Queued. So a preview that a human approved and nobody executed is swept on the next tick, and the sweep logs a count without naming what it cancelled.

What this is not

The receipt stays unspendable after a cancel. claim_approved_for_execution requires status = Queued (transactions.rs:667-678) and nothing moves a row back to Queued. This costs completeness of the trail, not privilege, and the fix should not be sold as closing an escalation.

Suggested shape

1. Factor the delete-plus-ApprovalRevoked body out of revoke_unconsumed_approval into a helper that runs inside a caller-supplied transaction.
2. cancel_queued opens an Immediate transaction, applies the status UPDATE, and calls that helper when the UPDATE affected a row.
3. cleanup_stale_queued does the same per row it cancels, so the event count matches the sweep count.
4. Mirror both in crates/sysknife-daemon/src/store/postgres.rs, where append_event is already available.

Acceptance

• Approve then cancel: no unconsumed row survives in transaction_approvals, and the event chain ends in approval_revoked for that transaction.
• Cancelling a transaction that was never approved writes no event.
• A TTL sweep over three approved and expired transactions writes three events, and sysknife audit verify reports the event chain intact.
• Both backends.

Difficulty: medium.

Getting started

CONTRIBUTING.md has the build and test commands, and docs/developer-guide.md covers the setup steps and how to reproduce each required check locally. No CLA and no copyright waiver. The project is MIT.

[vladimirrott]

@ITSMERNB a second one, for whenever you want daemon work rather than shell work.

#328 put you inside transport/listen.rs, so this is the neighbouring layer. An approval can end in three ways: consumed by an execute, cancelled, or swept when its TTL expires. Only the first writes an event. The other two remove the approval's effect and leave the event chain saying it is still outstanding, so sysknife audit verify reads a granted approval that was never used and never revoked, with nothing to distinguish "expired" from "still live".

The shape is the one this tracker keeps finding: a state change that happens without the record that is supposed to accompany it. Your #263 was the same class in packaging, where the declared mode and the live mode could disagree.

It is medium and it touches both storage backends, so it is a bigger piece than #331. Take whichever fits the time you have, or neither.

[vladimirrott]

Reproduced at v0.11.0, on both backends, and it is worse in combination than the body implies.

cancel_queued (transactions.rs:738) and cleanup_stale_queued (:715) both UPDATE … SET status = Canceled with no append_event and no revoke of the transaction_approvals row. store/postgres.rs:707 and :725 are symmetric, so neither backend has it.

A run through the real lifecycle:

[+] previewed + approved, receipt minted (ApprovalGranted event appended)
[+] audit_events rows after Approve: 1
[+] cancel_queued(txid) -> true
[+] transactions.status is now: "canceled"
[+] audit_events rows after Cancel: 1  (unchanged — no event appended)
[+] transaction_approvals row: consumed_at=None  (never revoked, never consumed)
[+] verify_chain:         Intact
[+] verify_event_chain:   Intact
[+] verify_event_binding: Consistent { bindings_checked: 0 }

Both chains verify clean. Neither can answer whether an approved high-risk action was stopped, or why.

Why it is worse than it reads

The cancellation's only record is the plain status column, and that column is not in ChainContent. update_status calls append_event zero times, so the terminal outcome of every action is unsigned. That half is tracked privately rather than here.

Composed, the two mean an attacker with database write access can cancel an action and forge Succeeded, or execute one and forge Canceled, and audit verify reports Intact either way. The orphaned approval row is the part this issue names; the missing outcome signature is what makes it undetectable.

Fixing this one on its own is still worth doing and is the smaller half: append a Revoked event in both cancel_queued and cleanup_stale_queued, in the same transaction as the status change, the way approve_transaction already pairs its row with its event.

@ITSMERNB this is the daemon-side issue I offered you yesterday. The repro above is the shape a fix has to invert.

[ITSMERNB]

Thanks for the detailed repro, Vladimir. The failure mode is clear. I will leave #251 unclaimed for now and take the smaller #331 path first when I pick up the next SysKnife item.

[vladimirrott]

@sonalisrisivani held this for you as a follow-up to your #375. It sits deeper in the daemon, in the approval lifecycle you were just working near. No pressure, and no deadline. Reply here that you want it and it is formally yours.

[sonalisrisivani]

I'd like to take this one as a follow-up to #375. Thanks for holding it for me!

[vladimirrott]

@sonalisrisivani two line numbers in the body had drifted, and you would have
worked from them. Corrected in place.

	body said	now
cancel_queued	postgres.rs:661	postgres.rs:725
cleanup_stale_queued	postgres.rs:643	postgres.rs:707

Recounted at d881d49:

$ grep -n 'fn cancel_queued\|fn cleanup_stale_queued' crates/sysknife-daemon/src/store/postgres.rs
707:    async fn cleanup_stale_queued(&self) -> Result<u64, TransactionStoreError> {
725:    async fn cancel_queued(&self, transaction_id: &str) -> Result<bool, TransactionStoreError> {

The body was accurate when I filed it on 2026-08-18. Both numbers moved because
#295 and #318 edited that file above the two functions:

$ git show bdfbe365951fa6d4b87e163b0955700eb84704c3:crates/sysknife-daemon/src/store/postgres.rs | grep -n 'fn cancel_queued\|fn cleanup_stale_queued'
643:    async fn cleanup_stale_queued(&self) -> Result<u64, TransactionStoreError> {
661:    async fn cancel_queued(&self, transaction_id: &str) -> Result<bool, TransactionStoreError> {

The SQLite side needed no change. crates/sysknife-daemon/src/transactions.rs:715
and :738 still land on cleanup_stale_queued and cancel_queued:

$ grep -n 'fn cancel_queued\|fn cleanup_stale_queued' crates/sysknife-daemon/src/transactions.rs
715:    pub fn cleanup_stale_queued(&self) -> Result<u64, TransactionStoreError> {
738:    pub fn cancel_queued(&self, transaction_id: &str) -> Result<bool, TransactionStoreError> {

The defect is unchanged. Neither backend revokes the transaction_approvals row
and neither appends an event.

One more thing: I assigned the issue to you. The claimed label is visible on the
issue page and nowhere else, so without the assignment it never reaches your
dashboard or an assignee:@me search, and somebody else reading the tracker has
to open the thread to learn it is taken.

[vladimirrott]

Correction to my own comment above: I trimmed that last block. The command
returns five lines, not two, because it also matches the three test functions.
Full output at d881d49:

$ grep -n 'fn cancel_queued\|fn cleanup_stale_queued' crates/sysknife-daemon/src/transactions.rs
715:    pub fn cleanup_stale_queued(&self) -> Result<u64, TransactionStoreError> {
738:    pub fn cancel_queued(&self, transaction_id: &str) -> Result<bool, TransactionStoreError> {
2418:    fn cancel_queued_cancels_a_queued_transaction_once() {
2442:    fn cancel_queued_refuses_a_running_transaction() {
2625:    fn cleanup_stale_queued_cancels_old_records() {

The two line numbers in the body are still right and nothing else changes. The
three tests at the bottom are worth your attention anyway, since they are where
the acceptance criteria will hang: none of them asserts on the event chain or on
transaction_approvals, which is the gap.

[vladimirrott]

Evidence for the last sentence above, which I owed you when I wrote it.

cancel_queued_cancels_a_queued_transaction_once (transactions.rs:2418) asserts
the return value and status. cleanup_stale_queued_cancels_old_records (:2625)
asserts the sweep count and two statuses. cancel_queued_refuses_a_running_transaction
(:2442) builds an approval and consumes it as setup, then asserts on the
cancel_queued return and on status. Nothing across the three reads back
transaction_approvals or the event chain:

$ awk 'NR>=2418 && NR<=2445' crates/sysknife-daemon/src/transactions.rs
$ awk 'NR>=2442 && NR<=2475' crates/sysknife-daemon/src/transactions.rs
$ awk 'NR>=2625 && NR<=2660' crates/sysknife-daemon/src/transactions.rs

Every assert in those three ranges is on a JobState, on a bool return, or on
the sweep count. That is why the bug survives a green test run, and it tells you
where the new test goes: same three functions, one extra assertion each on the
approval row and the appended event.

[sonalisrisivani]

I implemented the approval cancellation fix in PR #380: #380

Explicit cancellation and TTL cleanup now atomically revoke unconsumed approvals and append approval_revoked in both SQLite and Postgres. The focused tests cover approved and unapproved cancellation plus a three-transaction TTL sweep.