Skip to content

feat(cketh): act on a sweep's outcome - #11331

Closed
gregorydemay wants to merge 1 commit into
greg/DEFI-2926-sweep-request-depositsfrom
greg/DEFI-2926-sweep-queue-lifecycle
Closed

feat(cketh): act on a sweep's outcome#11331
gregorydemay wants to merge 1 commit into
greg/DEFI-2926-sweep-request-depositsfrom
greg/DEFI-2926-sweep-queue-lifecycle

Conversation

@gregorydemay

@gregorydemay gregorydemay commented Aug 26, 2026

Copy link
Copy Markdown
Contributor

Why

  • The sweep queue only knew how to hand deposits out: nothing marked them as taken, and nothing recorded what became of a sweep once its transaction was finalized.

What

  • A sweep now owns the deposits it takes: they are marked taken when its request is accepted, so no second sweep can move the same funds.
  • A sweep whose transaction failed drops its deposits from the queue. No funds are lost — a reverted sweep moved nothing — but the minter stops trying: the same batch would revert again on the next tick and burn more of the sweeper's gas. What to retry, and how, is DEFI-2981.
  • A sweep that moved its deposits releases them: each pair leaves the queue as it entered it, so it can be armed again for the next deposit to the same address.
  • A gauge reports where the queue's entries stand (sweepable vs. in flight).

@github-actions github-actions Bot added the feat label Aug 26, 2026
@gregorydemay
gregorydemay force-pushed the greg/DEFI-2926-sweep-queue-lifecycle branch 3 times, most recently from 1dc38bb to d411b16 Compare August 26, 2026 13:58
@gregorydemay gregorydemay changed the title feat(cketh): give the sweep queue a lifecycle beyond being taken feat(cketh): give the sweep queue a lifecycle and keep the authorizations it needs Aug 26, 2026
@gregorydemay gregorydemay changed the title feat(cketh): give the sweep queue a lifecycle and keep the authorizations it needs feat(cketh): act on a sweep's outcome and reuse the authorizations it signed Aug 26, 2026
A sweep now owns the deposits it takes: they are marked taken when the
request is accepted, dropped if its transaction fails (funds stay at the
deposit addresses; retrying is DEFI-2981), and released once it moved
them, so the pair can be armed again. A gauge reports where the queue's
entries stand.
@gregorydemay
gregorydemay force-pushed the greg/DEFI-2926-sweep-queue-lifecycle branch from a99a713 to f4a9467 Compare August 26, 2026 17:03
@gregorydemay gregorydemay changed the title feat(cketh): act on a sweep's outcome and reuse the authorizations it signed feat(cketh): act on a sweep's outcome Aug 26, 2026
@gregorydemay
gregorydemay requested a balanced review from Copilot August 26, 2026 17:06

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

Adds lifecycle tracking for ckERC20 sweep-queue deposits.

Changes:

  • Marks deposits as in flight when assigned to a sweep.
  • Removes deposits after successful or failed finalization.
  • Exposes sweepable and in-flight queue metrics with tests.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.

Show a summary per file
File Description
state/tests.rs Adds sweep lifecycle and nonce tests.
state/automatic_deposits/tests.rs Tests queue ownership and outcomes.
state/automatic_deposits/mod.rs Implements sweep tracking and queue depth.
state/audit.rs Applies sweep lifecycle events.
state.rs Handles finalized sweep outcomes.
main.rs Exports sweep queue metrics.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@gregorydemay
gregorydemay marked this pull request as ready for review August 27, 2026 06:25
@gregorydemay
gregorydemay requested a review from a team as a code owner August 27, 2026 06:25
@github-actions github-actions Bot added the @defi label Aug 27, 2026
@zeropath-ai

zeropath-ai Bot commented Aug 27, 2026

Copy link
Copy Markdown

No security or compliance issues detected. Reviewed everything up to f4a9467.

Security Overview
Detected Code Changes
Change Type Relevant files
Enhancement ► rs/ethereum/cketh/minter/src/main.rs
    Add metrics for sweep queue depth (in_flight, sweepable)
Enhancement ► rs/ethereum/cketh/minter/src/state.rs
    Add methods record_failed_sweep, record_successful_sweep, swept_deposits, and swept deposits tracking
Enhancement ► rs/ethereum/cketh/minter/src/state.rs
    Introduce swept_by tracking in SweepEntry and implement related logic
Enhancement ► rs/ethereum/cketh/minter/src/state/audit.rs
    Import TransactionStatus and integrate sweep scheduling/state transitions for success/failure
Enhancement ► rs/ethereum/cketh/minter/src/state/automatic_deposits/mod.rs
    Add sweep_targets_iter, record_sweep_scheduled, record_sweep_failed, record_sweep_succeeded, and sweep_queue_depth calculations; augment SweepTarget with accessors
Enhancement ► rs/ethereum/cketh/minter/src/state/automatic_deposits/tests.rs
    Extend tests with swept_by field in sweep_entry and comprehensive sweep scheduling/recording scenarios
Enhancement ► rs/ethereum/cketh/minter/src/state/tests.rs
    Add tests for sweeps behavior and interaction with queued deposits

@mbjorkqvist mbjorkqvist left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Thanks @gregorydemay!

Comment on lines +344 to +347
assert_eq!(
entry.swept_by, None,
"BUG: {request:?} was already taken by another sweep"
);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

IIUC, this could also occur if the deposits vec named the same pair twice. Adding some validation to SweepRequest::deposits (at construction and deserialization), which is currently missing, would help. Perhaps changing the type to pub deposits: BTreeMap<(Account, Address), DepositAddress> would be enough?

Comment on lines +877 to +897
#[test]
fn should_report_a_dropped_deposit_as_unknown_rather_than_awaiting_a_sweep() {
let mut deposits = queued();
assert_matches!(status(&deposits), Some(DepositStatus::AwaitingSweep(_)));
deposits.record_sweep_scheduled(SweepId(0), &[swept(usdc())]);

deposits.record_sweep_failed(SweepId(0), &[swept(usdc())]);

assert_eq!(status(&deposits), None);
}

#[test]
fn should_let_a_pair_whose_sweep_failed_be_armed_again() {
let mut deposits = queued();
deposits.record_sweep_scheduled(SweepId(0), &[swept(usdc())]);
deposits.record_sweep_failed(SweepId(0), &[swept(usdc())]);

let armed = deposits.watch_deposit(ts(0), account(0), usdc(), deposit_address(&account(0)));

assert_matches!(armed, Ok(_));
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This currently happens rather silently, and a user may end up wondering what happened to their deposit. Would it make sense to make this visible in the minter dashboard somehow (probably not in this PR, and maybe it's already tracked somewhere)?

@gregorydemay

Copy link
Copy Markdown
Contributor Author

🤖 Closing: superseded by the restructured stack #11353 (PRs #11359#11360#11362#11363#11342).

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants