duty-tracker: actually persist deposit setup duties on time

[ProofOfKeags]

turns out this code would never persist contract state after deposit setup processing. This means that we would lose this state if a node went down.

Description

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature/Enhancement (non-breaking change which adds functionality or enhances an existing one)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactor
• New or updated tests
• Dependency Update

Notes to Reviewers

Checklist

• I have performed a self-review of my code.
• I have commented my code where necessary.
• I have updated the documentation if needed.
• My changes do not introduce new warnings.
• I have added (where necessary) tests that prove my changes are effective or that my feature works.
• New and existing tests pass with my changes.

Related Issues

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 8 lines in your changes missing coverage. Please review.

Project coverage is 52.15%. Comparing base (9e015df) to head (c451921).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
crates/duty-tracker/src/contract_manager.rs	0.00%	8 Missing ⚠️

@@            Coverage Diff             @@
##             main     #222      +/-   ##
==========================================
- Coverage   52.24%   52.15%   -0.10%     
==========================================
  Files         152      152              
  Lines       22247    22244       -3     
==========================================
- Hits        11624    11601      -23     
- Misses      10623    10643      +20     

Files with missing lines	Coverage Δ
crates/duty-tracker/src/contract_manager.rs	0.00% <0.00%> (ø)

... and 3 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[barakshani]

What are the implications of this? I'm pretty sure we have done withdrawals after a restart on our envs (and I'm very hopeful that it was tested locally before making the restart PRs).

[storopoli]

ACK c451921

We cannot call empty() on an Iterator, hence this is not a 1-liner like I said.

[Rajil1213]

I'm pretty sure we have done withdrawals after a restart on our envs (and I'm very hopeful that it was tested locally before making the restart PRs).

@barakshani with self-nagging, even without persisting this state, it isn't exactly an issue. So, it should not cause any observable effects on the system.

[Rajil1213]

Nice catch.

[ProofOfKeags]

Yeah @barakshani this is just to cover an edge case where we can lose state