Payjoin persistence

[Mshehu5]

Description

#230 needed to be merged for this to go through
Address #149 also follow up to #200
This PR adds persistance to existing async payjoin integration
This introduces neccessary database model and tables also add commad for resume to allow interrupted sessions to be continued also a particular session either send or receive.
A history commad to view payjoin history and status has been added

Notes to the reviewers

Step to review this include making a payjoin transaction

Run a receiver to get a BIP21 URI then pass it to the sender as seen in docs

bdk-cli/README.md

Lines 121 to 141 in b9cf2ac

	To start a Payjoin session as the receiver with regtest RPC and example OHTTP relays:
	```
	cargo run --features rpc -- --network regtest wallet --wallet payjoin_wallet1 config --ext-descriptor "wpkh(tprv8ZgxMBicQKsPd2PoUEcGNDHPZmVWgtPYERAwMG6qHheX6LN4oaazp3qZU7mykiaAZga1ZB2SJJR6Mriyq8MocMs7QTe7toaabSwTWu5fRFz/84h/1h/0h/0/*)#8guqp7rn" --client-type rpc --database-type sqlite --url "127.0.0.1:18443"
	cargo run --features rpc -- wallet --wallet payjoin_wallet1 sync
	cargo run --features rpc -- wallet --wallet payjoin_wallet1 balance
	cargo run --features rpc -- wallet --wallet payjoin_wallet1 receive_payjoin --amount 400000 --max_fee_rate 1000 --directory "https://payjo.in" --ohttp_relay "https://pj.bobspacebkk.com" --ohttp_relay "https://pj.benalleng.com"
	```
	To send a Payjoin with regtest RPC and example OHTTP relays:
	```
	cargo run --features rpc -- --network regtest wallet --wallet payjoin_wallet2 config --ext-descriptor "wpkh(tprv8ZgxMBicQKsPfBxswkATvZRQ9kDdRbJPtHYZaZCARL2myxcK7DqsqPhRo2G2rRVHFPbowq63BE6S4k2pUMYeF2fUMTT63Q7zhoXtKsM1FaS/84'/1'/0'/0/*)#qf5gnqrf" --client-type rpc --database-type sqlite --url "127.0.0.1:18443"
	cargo run --features rpc -- wallet --wallet payjoin_wallet2 sync
	cargo run --features rpc -- wallet --wallet payjoin_wallet2 balance
	cargo run --features rpc -- wallet --wallet payjoin_wallet2 send_payjoin --ohttp_relay "https://pj.bobspacebkk.com" --ohttp_relay "https://pj.benalleng.com" --fee_rate 1 --uri "<URI>"
	```

To test resumption, interrupt either side with Ctrl+C mid-session then run resume on that side to continue. A few scenarios worth covering: receiver resuming after interrupt and sender resuming after interrupt. Use history after each scenario to confirm the session state was persisted correctly.

docs for this can be seen in 7e4ffd1

Checklists

All Submissions:

• I've signed all my commits
• I followed the contribution guidelines
• I ran cargo fmt and cargo clippy before committing

New Features:

• I've added docs for the new feature

[coveralls]

Pull Request Test Coverage Report for Build 22068931916

Details

• 0 of 763(0.0%) changed or added relevant lines in 5 files are covered.
• 5 unchanged lines in 3 files lost coverage.
• Overall coverage decreased (-1.9%) to 8.848%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/error.rs	0	21	0.0%
src/utils.rs	0	22	0.0%
src/handlers.rs	0	50	0.0%
src/payjoin/db.rs	0	262	0.0%
src/payjoin/mod.rs	0	408	0.0%

Files with Coverage Reduction	New Missed Lines	%
src/utils.rs	1	0.0%
src/handlers.rs	2	12.81%
src/payjoin/mod.rs	2	0.0%

Totals
Change from base Build 21153868360:	-1.9%
Covered Lines:	268
Relevant Lines:	3029

---

💛 - Coveralls

[tvpeter]

Thank you @Mshehu5 for working on this feature.

Below are some of the observations that I think will make the implementation better:

• I noticed that the implementation used only the sqlite db, and since sqlite is a db option in the project, I think it will be ideal if you also include implementation for redb db so users are free to choose any to use.
• The implementation does not provide for pruning/cleanup of data. Given that the db will tend to grow linearly and become sizable over time, I think it will be great to consider adding a pruning subcommand or mechanism that deletes irrelevant data.
• Since the save_event is generated at multiple transitions in a session, I think it will be great if you consider grouping such updates in a db transaction to ensure that entries are saved successfully.

I have also left some comments in the code.

Thank you.

[codecov]

Codecov Report

❌ Patch coverage is 68.46154% with 328 lines in your changes missing coverage. Please review.
✅ Project coverage is 28.87%. Comparing base (eea5ba9) to head (2f14a36).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
src/payjoin/mod.rs	26.21%	242 Missing ⚠️
src/handlers.rs	0.00%	33 Missing ⚠️
src/payjoin/db.rs	95.00%	30 Missing ⚠️
src/payjoin/ohttp.rs	73.33%	20 Missing ⚠️
src/error.rs	0.00%	3 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #242 +/- ##
===========================================
+ Coverage 11.36% 28.87% +17.51% 
===========================================
Files 8 9 +1 Lines 2807 3626 +819 ===========================================
+ Hits 319 1047 +728 - Misses 2488 2579 +91 

Flag	Coverage Δ
rust	28.87% <68.46%> (+17.51%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

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

[Mshehu5]

Thank you for the review!

Just wanted some clarifications

The implementation does not provide for pruning/cleanup of data. Given that the db will tend to grow linearly and become sizable over time, I think it will be great to consider adding a pruning subcommand or mechanism that deletes irrelevant data.

For this feature, how would you like it to be implemented? For example should we allow selecting a specific date or session to start pruning from? Or should it apply to all sessions older than a certain date? Alternatively should it target only expired or unsuccessful sessions?

I noticed that the implementation used only the sqlite db, and since sqlite is a db option in the project, I think it will be ideal if you also include implementation for redb db so users are free to choose any to use.

Also for the redb implementation most of the existing integrations have been built around SQLite so it made sense as the initial approach for this implementation. The Redb support may require some additional consideration and it would be good to align with the PayJoin team to ensure the approach is correct and consistent.
Given that would you prefer the Redb implementation to be included in this PR or would it be acceptable to handle it in a follow-up?

It would also be helpful to understand what you consider a hard requirement for this PR versus what can be iterated on in subsequent changes.

[vadim-anfv]

Hi @Mshehu5, thanks for this!

Could you update payjoin dependency to 1.0.0-rc.2 and run just pre-push?

I've got some errors from just pre-push like:

error[E0061]: this method takes 1 argument but 2 arguments were supplied
--> src/payjoin/mod.rs:691:30
|
691 | ... .check_payment(
| ^^^^^^^^^^^^^
...
704 | / ... |outpoint| {
705 || ... let utxo = self.wallet.get_utxo(outpoint);
706 || ... match utxo {
707 || ... Some(_) => Ok(false),
... |
710 || ... }
||___________________________- unexpected argument #2 of type `{closure@src/payjoin/mod.rs:704:33: 704:43}`

[Mshehu5]

@va-an Thanks for the review! I bumped Payjoin to 1.0.0-rc.2 and just pre-push passes locally. Mind giving it a try on your end? Would appreciate your feedback

[Mshehu5]

@tvpeter Would really appreciate your feedback on this: #242 (comment)

It would help move this PR forward.

[tvpeter]

For this feature, how would you like it to be implemented? For example should we allow selecting a specific date or session to start pruning from? Or should it apply to all sessions older than a certain date? Alternatively should it target only expired or unsuccessful sessions?

I think it should apply to all sessions within a specific timeframe, say anything older than 30 days, and if it can be implemented without adding another command, that would be great. This can even go into another PR.

Also for the redb implementation most of the existing integrations have been built around SQLite so it made sense as the initial approach for this implementation. The Redb support may require some additional consideration and it would be good to align with the PayJoin team to ensure the approach is correct and consistent. Given that would you prefer the Redb implementation to be included in this PR or would it be acceptable to handle it in a follow-up?

That is still fine. It can form another PR, but it's one of the things you can consider adding.

It would also be helpful to understand what you consider a hard requirement for this PR versus what can be iterated on in subsequent changes.

The current implementation covering SQLite is good enough (and the most important). Those others can serve as improvements to the persistence feature.

[Mshehu5]

@va-an Thank you for the review. The reqwest issue is fixed in 7ee0a71. The regression was caused by a separate merged PR that updated reqwest without enabling rustls. I have verified the fix locally and it should be ready for you to retest on your end.

[notmandatory]

tACK bdb7f38

Thanks for the detailed test steps, very helpful for manual testing. I verified canceling receive and separately sender flow works as expected.

Any other feature enhancements such as using a DB transaction for atomic updates, or improved error types I recommend making new issues for. These sort of small improvements would be better made after #278 and in a future milestone. I also don't think we need this to support the redb persistence right now. If someone needs it they can implement it in a new PR.

[tvpeter]

@Mshehu5 pls rebase

[Mshehu5]

Description

#230 needed to be merged for this to go through
Address #149 also follow up to #200
This PR adds persistance to existing async payjoin integration
This introduces neccessary database model and tables also add commad for resume to allow interrupted sessions to be continued also a particular session either send or receive.
A history commad to view payjoin history and status has been added

Notes to the reviewers

Step to review this include making a payjoin transaction

Run a receiver to get a BIP21 URI then pass it to the sender as seen in docs

bdk-cli/README.md

Lines 121 to 141 in b9cf2ac

	To start a Payjoin session as the receiver with regtest RPC and example OHTTP relays:
	```
	cargo run --features rpc -- --network regtest wallet --wallet payjoin_wallet1 config --ext-descriptor "wpkh(tprv8ZgxMBicQKsPd2PoUEcGNDHPZmVWgtPYERAwMG6qHheX6LN4oaazp3qZU7mykiaAZga1ZB2SJJR6Mriyq8MocMs7QTe7toaabSwTWu5fRFz/84h/1h/0h/0/*)#8guqp7rn" --client-type rpc --database-type sqlite --url "127.0.0.1:18443"
	cargo run --features rpc -- wallet --wallet payjoin_wallet1 sync
	cargo run --features rpc -- wallet --wallet payjoin_wallet1 balance
	cargo run --features rpc -- wallet --wallet payjoin_wallet1 receive_payjoin --amount 400000 --max_fee_rate 1000 --directory "https://payjo.in" --ohttp_relay "https://pj.bobspacebkk.com" --ohttp_relay "https://pj.benalleng.com"
	```
	To send a Payjoin with regtest RPC and example OHTTP relays:
	```
	cargo run --features rpc -- --network regtest wallet --wallet payjoin_wallet2 config --ext-descriptor "wpkh(tprv8ZgxMBicQKsPfBxswkATvZRQ9kDdRbJPtHYZaZCARL2myxcK7DqsqPhRo2G2rRVHFPbowq63BE6S4k2pUMYeF2fUMTT63Q7zhoXtKsM1FaS/84'/1'/0'/0/*)#qf5gnqrf" --client-type rpc --database-type sqlite --url "127.0.0.1:18443"
	cargo run --features rpc -- wallet --wallet payjoin_wallet2 sync
	cargo run --features rpc -- wallet --wallet payjoin_wallet2 balance
	cargo run --features rpc -- wallet --wallet payjoin_wallet2 send_payjoin --ohttp_relay "https://pj.bobspacebkk.com" --ohttp_relay "https://pj.benalleng.com" --fee_rate 1 --uri "<URI>"
	```

To test resumption, interrupt either side with Ctrl+C mid-session then run resume on that side to continue. A few scenarios worth covering: receiver resuming after interrupt and sender resuming after interrupt. Use history after each scenario to confirm the session state was persisted correctly.

docs for this can be seen in 7e4ffd1

Checklists

All Submissions:

• I've signed all my commits
• I followed the contribution guidelines
• I ran cargo fmt and cargo clippy before committing

New Features:

• I've added docs for the new feature

[coveralls]

Pull Request Test Coverage Report for Build 22068931916

Details

• 0 of 763(0.0%) changed or added relevant lines in 5 files are covered.
• 5 unchanged lines in 3 files lost coverage.
• Overall coverage decreased (-1.9%) to 8.848%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/error.rs	0	21	0.0%
src/utils.rs	0	22	0.0%
src/handlers.rs	0	50	0.0%
src/payjoin/db.rs	0	262	0.0%
src/payjoin/mod.rs	0	408	0.0%

Files with Coverage Reduction	New Missed Lines	%
src/utils.rs	1	0.0%
src/handlers.rs	2	12.81%
src/payjoin/mod.rs	2	0.0%

Totals
Change from base Build 21153868360:	-1.9%
Covered Lines:	268
Relevant Lines:	3029

---

💛 - Coveralls

[tvpeter]

Thank you @Mshehu5 for working on this feature.

Below are some of the observations that I think will make the implementation better:

• I noticed that the implementation used only the sqlite db, and since sqlite is a db option in the project, I think it will be ideal if you also include implementation for redb db so users are free to choose any to use.
• The implementation does not provide for pruning/cleanup of data. Given that the db will tend to grow linearly and become sizable over time, I think it will be great to consider adding a pruning subcommand or mechanism that deletes irrelevant data.
• Since the save_event is generated at multiple transitions in a session, I think it will be great if you consider grouping such updates in a db transaction to ensure that entries are saved successfully.

I have also left some comments in the code.

Thank you.

[codecov]

Codecov Report

❌ Patch coverage is 68.46154% with 328 lines in your changes missing coverage. Please review.
✅ Project coverage is 28.87%. Comparing base (eea5ba9) to head (2f14a36).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
src/payjoin/mod.rs	26.21%	242 Missing ⚠️
src/handlers.rs	0.00%	33 Missing ⚠️
src/payjoin/db.rs	95.00%	30 Missing ⚠️
src/payjoin/ohttp.rs	73.33%	20 Missing ⚠️
src/error.rs	0.00%	3 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #242 +/- ##
===========================================
+ Coverage 11.36% 28.87% +17.51% 
===========================================
Files 8 9 +1 Lines 2807 3626 +819 ===========================================
+ Hits 319 1047 +728 - Misses 2488 2579 +91 

Flag	Coverage Δ
rust	28.87% <68.46%> (+17.51%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

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

[Mshehu5]

Thank you for the review!

Just wanted some clarifications

The implementation does not provide for pruning/cleanup of data. Given that the db will tend to grow linearly and become sizable over time, I think it will be great to consider adding a pruning subcommand or mechanism that deletes irrelevant data.

For this feature, how would you like it to be implemented? For example should we allow selecting a specific date or session to start pruning from? Or should it apply to all sessions older than a certain date? Alternatively should it target only expired or unsuccessful sessions?

I noticed that the implementation used only the sqlite db, and since sqlite is a db option in the project, I think it will be ideal if you also include implementation for redb db so users are free to choose any to use.

Also for the redb implementation most of the existing integrations have been built around SQLite so it made sense as the initial approach for this implementation. The Redb support may require some additional consideration and it would be good to align with the PayJoin team to ensure the approach is correct and consistent.
Given that would you prefer the Redb implementation to be included in this PR or would it be acceptable to handle it in a follow-up?

It would also be helpful to understand what you consider a hard requirement for this PR versus what can be iterated on in subsequent changes.

[vadim-anfv]

Hi @Mshehu5, thanks for this!

Could you update payjoin dependency to 1.0.0-rc.2 and run just pre-push?

I've got some errors from just pre-push like:

error[E0061]: this method takes 1 argument but 2 arguments were supplied
--> src/payjoin/mod.rs:691:30
|
691 | ... .check_payment(
| ^^^^^^^^^^^^^
...
704 | / ... |outpoint| {
705 || ... let utxo = self.wallet.get_utxo(outpoint);
706 || ... match utxo {
707 || ... Some(_) => Ok(false),
... |
710 || ... }
||___________________________- unexpected argument #2 of type `{closure@src/payjoin/mod.rs:704:33: 704:43}`

[Mshehu5]

@va-an Thanks for the review! I bumped Payjoin to 1.0.0-rc.2 and just pre-push passes locally. Mind giving it a try on your end? Would appreciate your feedback

[Mshehu5]

@tvpeter Would really appreciate your feedback on this: #242 (comment)

It would help move this PR forward.

[tvpeter]

For this feature, how would you like it to be implemented? For example should we allow selecting a specific date or session to start pruning from? Or should it apply to all sessions older than a certain date? Alternatively should it target only expired or unsuccessful sessions?

I think it should apply to all sessions within a specific timeframe, say anything older than 30 days, and if it can be implemented without adding another command, that would be great. This can even go into another PR.

Also for the redb implementation most of the existing integrations have been built around SQLite so it made sense as the initial approach for this implementation. The Redb support may require some additional consideration and it would be good to align with the PayJoin team to ensure the approach is correct and consistent. Given that would you prefer the Redb implementation to be included in this PR or would it be acceptable to handle it in a follow-up?

That is still fine. It can form another PR, but it's one of the things you can consider adding.

It would also be helpful to understand what you consider a hard requirement for this PR versus what can be iterated on in subsequent changes.

The current implementation covering SQLite is good enough (and the most important). Those others can serve as improvements to the persistence feature.

[Mshehu5]

@va-an Thank you for the review. The reqwest issue is fixed in 7ee0a71. The regression was caused by a separate merged PR that updated reqwest without enabling rustls. I have verified the fix locally and it should be ready for you to retest on your end.

[notmandatory]

tACK bdb7f38

Thanks for the detailed test steps, very helpful for manual testing. I verified canceling receive and separately sender flow works as expected.

Any other feature enhancements such as using a DB transaction for atomic updates, or improved error types I recommend making new issues for. These sort of small improvements would be better made after #278 and in a future milestone. I also don't think we need this to support the redb persistence right now. If someone needs it they can implement it in a new PR.

[tvpeter]

@Mshehu5 pls rebase

[Mshehu5]

Description

#230 needed to be merged for this to go through
Address #149 also follow up to #200
This PR adds persistance to existing async payjoin integration
This introduces neccessary database model and tables also add commad for resume to allow interrupted sessions to be continued also a particular session either send or receive.
A history commad to view payjoin history and status has been added

Notes to the reviewers

Step to review this include making a payjoin transaction

Run a receiver to get a BIP21 URI then pass it to the sender as seen in docs

bdk-cli/README.md

Lines 121 to 141 in b9cf2ac

	To start a Payjoin session as the receiver with regtest RPC and example OHTTP relays:
	```
	cargo run --features rpc -- --network regtest wallet --wallet payjoin_wallet1 config --ext-descriptor "wpkh(tprv8ZgxMBicQKsPd2PoUEcGNDHPZmVWgtPYERAwMG6qHheX6LN4oaazp3qZU7mykiaAZga1ZB2SJJR6Mriyq8MocMs7QTe7toaabSwTWu5fRFz/84h/1h/0h/0/*)#8guqp7rn" --client-type rpc --database-type sqlite --url "127.0.0.1:18443"
	cargo run --features rpc -- wallet --wallet payjoin_wallet1 sync
	cargo run --features rpc -- wallet --wallet payjoin_wallet1 balance
	cargo run --features rpc -- wallet --wallet payjoin_wallet1 receive_payjoin --amount 400000 --max_fee_rate 1000 --directory "https://payjo.in" --ohttp_relay "https://pj.bobspacebkk.com" --ohttp_relay "https://pj.benalleng.com"
	```
	To send a Payjoin with regtest RPC and example OHTTP relays:
	```
	cargo run --features rpc -- --network regtest wallet --wallet payjoin_wallet2 config --ext-descriptor "wpkh(tprv8ZgxMBicQKsPfBxswkATvZRQ9kDdRbJPtHYZaZCARL2myxcK7DqsqPhRo2G2rRVHFPbowq63BE6S4k2pUMYeF2fUMTT63Q7zhoXtKsM1FaS/84'/1'/0'/0/*)#qf5gnqrf" --client-type rpc --database-type sqlite --url "127.0.0.1:18443"
	cargo run --features rpc -- wallet --wallet payjoin_wallet2 sync
	cargo run --features rpc -- wallet --wallet payjoin_wallet2 balance
	cargo run --features rpc -- wallet --wallet payjoin_wallet2 send_payjoin --ohttp_relay "https://pj.bobspacebkk.com" --ohttp_relay "https://pj.benalleng.com" --fee_rate 1 --uri "<URI>"
	```

To test resumption, interrupt either side with Ctrl+C mid-session then run resume on that side to continue. A few scenarios worth covering: receiver resuming after interrupt and sender resuming after interrupt. Use history after each scenario to confirm the session state was persisted correctly.

docs for this can be seen in 7e4ffd1

Checklists

All Submissions:

• I've signed all my commits
• I followed the contribution guidelines
• I ran cargo fmt and cargo clippy before committing

New Features:

• I've added docs for the new feature

[coveralls]

Pull Request Test Coverage Report for Build 22068931916

Details

• 0 of 763(0.0%) changed or added relevant lines in 5 files are covered.
• 5 unchanged lines in 3 files lost coverage.
• Overall coverage decreased (-1.9%) to 8.848%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/error.rs	0	21	0.0%
src/utils.rs	0	22	0.0%
src/handlers.rs	0	50	0.0%
src/payjoin/db.rs	0	262	0.0%
src/payjoin/mod.rs	0	408	0.0%

Files with Coverage Reduction	New Missed Lines	%
src/utils.rs	1	0.0%
src/handlers.rs	2	12.81%
src/payjoin/mod.rs	2	0.0%

Totals
Change from base Build 21153868360:	-1.9%
Covered Lines:	268
Relevant Lines:	3029

---

💛 - Coveralls

[tvpeter]

Thank you @Mshehu5 for working on this feature.

Below are some of the observations that I think will make the implementation better:

• I noticed that the implementation used only the sqlite db, and since sqlite is a db option in the project, I think it will be ideal if you also include implementation for redb db so users are free to choose any to use.
• The implementation does not provide for pruning/cleanup of data. Given that the db will tend to grow linearly and become sizable over time, I think it will be great to consider adding a pruning subcommand or mechanism that deletes irrelevant data.
• Since the save_event is generated at multiple transitions in a session, I think it will be great if you consider grouping such updates in a db transaction to ensure that entries are saved successfully.

I have also left some comments in the code.

Thank you.

[codecov]

Codecov Report

❌ Patch coverage is 68.46154% with 328 lines in your changes missing coverage. Please review.
✅ Project coverage is 28.87%. Comparing base (eea5ba9) to head (2f14a36).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
src/payjoin/mod.rs	26.21%	242 Missing ⚠️
src/handlers.rs	0.00%	33 Missing ⚠️
src/payjoin/db.rs	95.00%	30 Missing ⚠️
src/payjoin/ohttp.rs	73.33%	20 Missing ⚠️
src/error.rs	0.00%	3 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #242 +/- ##
===========================================
+ Coverage 11.36% 28.87% +17.51% 
===========================================
Files 8 9 +1 Lines 2807 3626 +819 ===========================================
+ Hits 319 1047 +728 - Misses 2488 2579 +91 

Flag	Coverage Δ
rust	28.87% <68.46%> (+17.51%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

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

[Mshehu5]

Thank you for the review!

Just wanted some clarifications

The implementation does not provide for pruning/cleanup of data. Given that the db will tend to grow linearly and become sizable over time, I think it will be great to consider adding a pruning subcommand or mechanism that deletes irrelevant data.

For this feature, how would you like it to be implemented? For example should we allow selecting a specific date or session to start pruning from? Or should it apply to all sessions older than a certain date? Alternatively should it target only expired or unsuccessful sessions?

I noticed that the implementation used only the sqlite db, and since sqlite is a db option in the project, I think it will be ideal if you also include implementation for redb db so users are free to choose any to use.

Also for the redb implementation most of the existing integrations have been built around SQLite so it made sense as the initial approach for this implementation. The Redb support may require some additional consideration and it would be good to align with the PayJoin team to ensure the approach is correct and consistent.
Given that would you prefer the Redb implementation to be included in this PR or would it be acceptable to handle it in a follow-up?

It would also be helpful to understand what you consider a hard requirement for this PR versus what can be iterated on in subsequent changes.

[vadim-anfv]

Hi @Mshehu5, thanks for this!

Could you update payjoin dependency to 1.0.0-rc.2 and run just pre-push?

I've got some errors from just pre-push like:

error[E0061]: this method takes 1 argument but 2 arguments were supplied
--> src/payjoin/mod.rs:691:30
|
691 | ... .check_payment(
| ^^^^^^^^^^^^^
...
704 | / ... |outpoint| {
705 || ... let utxo = self.wallet.get_utxo(outpoint);
706 || ... match utxo {
707 || ... Some(_) => Ok(false),
... |
710 || ... }
||___________________________- unexpected argument #2 of type `{closure@src/payjoin/mod.rs:704:33: 704:43}`

[Mshehu5]

@va-an Thanks for the review! I bumped Payjoin to 1.0.0-rc.2 and just pre-push passes locally. Mind giving it a try on your end? Would appreciate your feedback

[Mshehu5]

@tvpeter Would really appreciate your feedback on this: #242 (comment)

It would help move this PR forward.

[tvpeter]

For this feature, how would you like it to be implemented? For example should we allow selecting a specific date or session to start pruning from? Or should it apply to all sessions older than a certain date? Alternatively should it target only expired or unsuccessful sessions?

I think it should apply to all sessions within a specific timeframe, say anything older than 30 days, and if it can be implemented without adding another command, that would be great. This can even go into another PR.

Also for the redb implementation most of the existing integrations have been built around SQLite so it made sense as the initial approach for this implementation. The Redb support may require some additional consideration and it would be good to align with the PayJoin team to ensure the approach is correct and consistent. Given that would you prefer the Redb implementation to be included in this PR or would it be acceptable to handle it in a follow-up?

That is still fine. It can form another PR, but it's one of the things you can consider adding.

It would also be helpful to understand what you consider a hard requirement for this PR versus what can be iterated on in subsequent changes.

The current implementation covering SQLite is good enough (and the most important). Those others can serve as improvements to the persistence feature.

[Mshehu5]

@va-an Thank you for the review. The reqwest issue is fixed in 7ee0a71. The regression was caused by a separate merged PR that updated reqwest without enabling rustls. I have verified the fix locally and it should be ready for you to retest on your end.

[notmandatory]

tACK bdb7f38

Thanks for the detailed test steps, very helpful for manual testing. I verified canceling receive and separately sender flow works as expected.

Any other feature enhancements such as using a DB transaction for atomic updates, or improved error types I recommend making new issues for. These sort of small improvements would be better made after #278 and in a future milestone. I also don't think we need this to support the redb persistence right now. If someone needs it they can implement it in a new PR.

[tvpeter]

@Mshehu5 pls rebase

[Mshehu5]

Description

#230 needed to be merged for this to go through
Address #149 also follow up to #200
This PR adds persistance to existing async payjoin integration
This introduces neccessary database model and tables also add commad for resume to allow interrupted sessions to be continued also a particular session either send or receive.
A history commad to view payjoin history and status has been added

Notes to the reviewers

Step to review this include making a payjoin transaction

Run a receiver to get a BIP21 URI then pass it to the sender as seen in docs

bdk-cli/README.md

Lines 121 to 141 in b9cf2ac

	To start a Payjoin session as the receiver with regtest RPC and example OHTTP relays:
	```
	cargo run --features rpc -- --network regtest wallet --wallet payjoin_wallet1 config --ext-descriptor "wpkh(tprv8ZgxMBicQKsPd2PoUEcGNDHPZmVWgtPYERAwMG6qHheX6LN4oaazp3qZU7mykiaAZga1ZB2SJJR6Mriyq8MocMs7QTe7toaabSwTWu5fRFz/84h/1h/0h/0/*)#8guqp7rn" --client-type rpc --database-type sqlite --url "127.0.0.1:18443"
	cargo run --features rpc -- wallet --wallet payjoin_wallet1 sync
	cargo run --features rpc -- wallet --wallet payjoin_wallet1 balance
	cargo run --features rpc -- wallet --wallet payjoin_wallet1 receive_payjoin --amount 400000 --max_fee_rate 1000 --directory "https://payjo.in" --ohttp_relay "https://pj.bobspacebkk.com" --ohttp_relay "https://pj.benalleng.com"
	```
	To send a Payjoin with regtest RPC and example OHTTP relays:
	```
	cargo run --features rpc -- --network regtest wallet --wallet payjoin_wallet2 config --ext-descriptor "wpkh(tprv8ZgxMBicQKsPfBxswkATvZRQ9kDdRbJPtHYZaZCARL2myxcK7DqsqPhRo2G2rRVHFPbowq63BE6S4k2pUMYeF2fUMTT63Q7zhoXtKsM1FaS/84'/1'/0'/0/*)#qf5gnqrf" --client-type rpc --database-type sqlite --url "127.0.0.1:18443"
	cargo run --features rpc -- wallet --wallet payjoin_wallet2 sync
	cargo run --features rpc -- wallet --wallet payjoin_wallet2 balance
	cargo run --features rpc -- wallet --wallet payjoin_wallet2 send_payjoin --ohttp_relay "https://pj.bobspacebkk.com" --ohttp_relay "https://pj.benalleng.com" --fee_rate 1 --uri "<URI>"
	```

To test resumption, interrupt either side with Ctrl+C mid-session then run resume on that side to continue. A few scenarios worth covering: receiver resuming after interrupt and sender resuming after interrupt. Use history after each scenario to confirm the session state was persisted correctly.

docs for this can be seen in 7e4ffd1

Checklists

All Submissions:

• I've signed all my commits
• I followed the contribution guidelines
• I ran cargo fmt and cargo clippy before committing

New Features:

• I've added docs for the new feature

[coveralls]

Pull Request Test Coverage Report for Build 22068931916

Details

• 0 of 763(0.0%) changed or added relevant lines in 5 files are covered.
• 5 unchanged lines in 3 files lost coverage.
• Overall coverage decreased (-1.9%) to 8.848%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/error.rs	0	21	0.0%
src/utils.rs	0	22	0.0%
src/handlers.rs	0	50	0.0%
src/payjoin/db.rs	0	262	0.0%
src/payjoin/mod.rs	0	408	0.0%

Files with Coverage Reduction	New Missed Lines	%
src/utils.rs	1	0.0%
src/handlers.rs	2	12.81%
src/payjoin/mod.rs	2	0.0%

Totals
Change from base Build 21153868360:	-1.9%
Covered Lines:	268
Relevant Lines:	3029

---

💛 - Coveralls

[tvpeter]

Thank you @Mshehu5 for working on this feature.

Below are some of the observations that I think will make the implementation better:

• I noticed that the implementation used only the sqlite db, and since sqlite is a db option in the project, I think it will be ideal if you also include implementation for redb db so users are free to choose any to use.
• The implementation does not provide for pruning/cleanup of data. Given that the db will tend to grow linearly and become sizable over time, I think it will be great to consider adding a pruning subcommand or mechanism that deletes irrelevant data.
• Since the save_event is generated at multiple transitions in a session, I think it will be great if you consider grouping such updates in a db transaction to ensure that entries are saved successfully.

I have also left some comments in the code.

Thank you.

[codecov]

Codecov Report

❌ Patch coverage is 68.46154% with 328 lines in your changes missing coverage. Please review.
✅ Project coverage is 28.87%. Comparing base (eea5ba9) to head (2f14a36).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
src/payjoin/mod.rs	26.21%	242 Missing ⚠️
src/handlers.rs	0.00%	33 Missing ⚠️
src/payjoin/db.rs	95.00%	30 Missing ⚠️
src/payjoin/ohttp.rs	73.33%	20 Missing ⚠️
src/error.rs	0.00%	3 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #242 +/- ##
===========================================
+ Coverage 11.36% 28.87% +17.51% 
===========================================
Files 8 9 +1 Lines 2807 3626 +819 ===========================================
+ Hits 319 1047 +728 - Misses 2488 2579 +91 

Flag	Coverage Δ
rust	28.87% <68.46%> (+17.51%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

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

[Mshehu5]

Thank you for the review!

Just wanted some clarifications

The implementation does not provide for pruning/cleanup of data. Given that the db will tend to grow linearly and become sizable over time, I think it will be great to consider adding a pruning subcommand or mechanism that deletes irrelevant data.

For this feature, how would you like it to be implemented? For example should we allow selecting a specific date or session to start pruning from? Or should it apply to all sessions older than a certain date? Alternatively should it target only expired or unsuccessful sessions?

I noticed that the implementation used only the sqlite db, and since sqlite is a db option in the project, I think it will be ideal if you also include implementation for redb db so users are free to choose any to use.

Also for the redb implementation most of the existing integrations have been built around SQLite so it made sense as the initial approach for this implementation. The Redb support may require some additional consideration and it would be good to align with the PayJoin team to ensure the approach is correct and consistent.
Given that would you prefer the Redb implementation to be included in this PR or would it be acceptable to handle it in a follow-up?

It would also be helpful to understand what you consider a hard requirement for this PR versus what can be iterated on in subsequent changes.

[vadim-anfv]

Hi @Mshehu5, thanks for this!

Could you update payjoin dependency to 1.0.0-rc.2 and run just pre-push?

I've got some errors from just pre-push like:

error[E0061]: this method takes 1 argument but 2 arguments were supplied
--> src/payjoin/mod.rs:691:30
|
691 | ... .check_payment(
| ^^^^^^^^^^^^^
...
704 | / ... |outpoint| {
705 || ... let utxo = self.wallet.get_utxo(outpoint);
706 || ... match utxo {
707 || ... Some(_) => Ok(false),
... |
710 || ... }
||___________________________- unexpected argument #2 of type `{closure@src/payjoin/mod.rs:704:33: 704:43}`

[Mshehu5]

@va-an Thanks for the review! I bumped Payjoin to 1.0.0-rc.2 and just pre-push passes locally. Mind giving it a try on your end? Would appreciate your feedback

[Mshehu5]

@tvpeter Would really appreciate your feedback on this: #242 (comment)

It would help move this PR forward.

[tvpeter]

For this feature, how would you like it to be implemented? For example should we allow selecting a specific date or session to start pruning from? Or should it apply to all sessions older than a certain date? Alternatively should it target only expired or unsuccessful sessions?

I think it should apply to all sessions within a specific timeframe, say anything older than 30 days, and if it can be implemented without adding another command, that would be great. This can even go into another PR.

Also for the redb implementation most of the existing integrations have been built around SQLite so it made sense as the initial approach for this implementation. The Redb support may require some additional consideration and it would be good to align with the PayJoin team to ensure the approach is correct and consistent. Given that would you prefer the Redb implementation to be included in this PR or would it be acceptable to handle it in a follow-up?

That is still fine. It can form another PR, but it's one of the things you can consider adding.

It would also be helpful to understand what you consider a hard requirement for this PR versus what can be iterated on in subsequent changes.

The current implementation covering SQLite is good enough (and the most important). Those others can serve as improvements to the persistence feature.

[Mshehu5]

@va-an Thank you for the review. The reqwest issue is fixed in 7ee0a71. The regression was caused by a separate merged PR that updated reqwest without enabling rustls. I have verified the fix locally and it should be ready for you to retest on your end.

[notmandatory]

tACK bdb7f38

Thanks for the detailed test steps, very helpful for manual testing. I verified canceling receive and separately sender flow works as expected.

Any other feature enhancements such as using a DB transaction for atomic updates, or improved error types I recommend making new issues for. These sort of small improvements would be better made after #278 and in a future milestone. I also don't think we need this to support the redb persistence right now. If someone needs it they can implement it in a new PR.

[tvpeter]

@Mshehu5 pls rebase

[Mshehu5]

Description

#230 needed to be merged for this to go through
Address #149 also follow up to #200
This PR adds persistance to existing async payjoin integration
This introduces neccessary database model and tables also add commad for resume to allow interrupted sessions to be continued also a particular session either send or receive.
A history commad to view payjoin history and status has been added

Notes to the reviewers

Step to review this include making a payjoin transaction

Run a receiver to get a BIP21 URI then pass it to the sender as seen in docs

bdk-cli/README.md

Lines 121 to 141 in b9cf2ac

	To start a Payjoin session as the receiver with regtest RPC and example OHTTP relays:
	```
	cargo run --features rpc -- --network regtest wallet --wallet payjoin_wallet1 config --ext-descriptor "wpkh(tprv8ZgxMBicQKsPd2PoUEcGNDHPZmVWgtPYERAwMG6qHheX6LN4oaazp3qZU7mykiaAZga1ZB2SJJR6Mriyq8MocMs7QTe7toaabSwTWu5fRFz/84h/1h/0h/0/*)#8guqp7rn" --client-type rpc --database-type sqlite --url "127.0.0.1:18443"
	cargo run --features rpc -- wallet --wallet payjoin_wallet1 sync
	cargo run --features rpc -- wallet --wallet payjoin_wallet1 balance
	cargo run --features rpc -- wallet --wallet payjoin_wallet1 receive_payjoin --amount 400000 --max_fee_rate 1000 --directory "https://payjo.in" --ohttp_relay "https://pj.bobspacebkk.com" --ohttp_relay "https://pj.benalleng.com"
	```
	To send a Payjoin with regtest RPC and example OHTTP relays:
	```
	cargo run --features rpc -- --network regtest wallet --wallet payjoin_wallet2 config --ext-descriptor "wpkh(tprv8ZgxMBicQKsPfBxswkATvZRQ9kDdRbJPtHYZaZCARL2myxcK7DqsqPhRo2G2rRVHFPbowq63BE6S4k2pUMYeF2fUMTT63Q7zhoXtKsM1FaS/84'/1'/0'/0/*)#qf5gnqrf" --client-type rpc --database-type sqlite --url "127.0.0.1:18443"
	cargo run --features rpc -- wallet --wallet payjoin_wallet2 sync
	cargo run --features rpc -- wallet --wallet payjoin_wallet2 balance
	cargo run --features rpc -- wallet --wallet payjoin_wallet2 send_payjoin --ohttp_relay "https://pj.bobspacebkk.com" --ohttp_relay "https://pj.benalleng.com" --fee_rate 1 --uri "<URI>"
	```

To test resumption, interrupt either side with Ctrl+C mid-session then run resume on that side to continue. A few scenarios worth covering: receiver resuming after interrupt and sender resuming after interrupt. Use history after each scenario to confirm the session state was persisted correctly.

docs for this can be seen in 7e4ffd1

Checklists

All Submissions:

• I've signed all my commits
• I followed the contribution guidelines
• I ran cargo fmt and cargo clippy before committing

New Features:

• I've added docs for the new feature

[coveralls]

Pull Request Test Coverage Report for Build 22068931916

Details

• 0 of 763(0.0%) changed or added relevant lines in 5 files are covered.
• 5 unchanged lines in 3 files lost coverage.
• Overall coverage decreased (-1.9%) to 8.848%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/error.rs	0	21	0.0%
src/utils.rs	0	22	0.0%
src/handlers.rs	0	50	0.0%
src/payjoin/db.rs	0	262	0.0%
src/payjoin/mod.rs	0	408	0.0%

Files with Coverage Reduction	New Missed Lines	%
src/utils.rs	1	0.0%
src/handlers.rs	2	12.81%
src/payjoin/mod.rs	2	0.0%

Totals
Change from base Build 21153868360:	-1.9%
Covered Lines:	268
Relevant Lines:	3029

---

💛 - Coveralls

[tvpeter]

Thank you @Mshehu5 for working on this feature.

Below are some of the observations that I think will make the implementation better:

• I noticed that the implementation used only the sqlite db, and since sqlite is a db option in the project, I think it will be ideal if you also include implementation for redb db so users are free to choose any to use.
• The implementation does not provide for pruning/cleanup of data. Given that the db will tend to grow linearly and become sizable over time, I think it will be great to consider adding a pruning subcommand or mechanism that deletes irrelevant data.
• Since the save_event is generated at multiple transitions in a session, I think it will be great if you consider grouping such updates in a db transaction to ensure that entries are saved successfully.

I have also left some comments in the code.

Thank you.

[codecov]

Codecov Report

❌ Patch coverage is 68.46154% with 328 lines in your changes missing coverage. Please review.
✅ Project coverage is 28.87%. Comparing base (eea5ba9) to head (2f14a36).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
src/payjoin/mod.rs	26.21%	242 Missing ⚠️
src/handlers.rs	0.00%	33 Missing ⚠️
src/payjoin/db.rs	95.00%	30 Missing ⚠️
src/payjoin/ohttp.rs	73.33%	20 Missing ⚠️
src/error.rs	0.00%	3 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #242 +/- ##
===========================================
+ Coverage 11.36% 28.87% +17.51% 
===========================================
Files 8 9 +1 Lines 2807 3626 +819 ===========================================
+ Hits 319 1047 +728 - Misses 2488 2579 +91 

Flag	Coverage Δ
rust	28.87% <68.46%> (+17.51%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

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

[Mshehu5]

Thank you for the review!

Just wanted some clarifications

The implementation does not provide for pruning/cleanup of data. Given that the db will tend to grow linearly and become sizable over time, I think it will be great to consider adding a pruning subcommand or mechanism that deletes irrelevant data.

For this feature, how would you like it to be implemented? For example should we allow selecting a specific date or session to start pruning from? Or should it apply to all sessions older than a certain date? Alternatively should it target only expired or unsuccessful sessions?

I noticed that the implementation used only the sqlite db, and since sqlite is a db option in the project, I think it will be ideal if you also include implementation for redb db so users are free to choose any to use.

Also for the redb implementation most of the existing integrations have been built around SQLite so it made sense as the initial approach for this implementation. The Redb support may require some additional consideration and it would be good to align with the PayJoin team to ensure the approach is correct and consistent.
Given that would you prefer the Redb implementation to be included in this PR or would it be acceptable to handle it in a follow-up?

It would also be helpful to understand what you consider a hard requirement for this PR versus what can be iterated on in subsequent changes.

[vadim-anfv]

Hi @Mshehu5, thanks for this!

Could you update payjoin dependency to 1.0.0-rc.2 and run just pre-push?

I've got some errors from just pre-push like:

error[E0061]: this method takes 1 argument but 2 arguments were supplied
--> src/payjoin/mod.rs:691:30
|
691 | ... .check_payment(
| ^^^^^^^^^^^^^
...
704 | / ... |outpoint| {
705 || ... let utxo = self.wallet.get_utxo(outpoint);
706 || ... match utxo {
707 || ... Some(_) => Ok(false),
... |
710 || ... }
||___________________________- unexpected argument #2 of type `{closure@src/payjoin/mod.rs:704:33: 704:43}`

[Mshehu5]

@va-an Thanks for the review! I bumped Payjoin to 1.0.0-rc.2 and just pre-push passes locally. Mind giving it a try on your end? Would appreciate your feedback

[Mshehu5]

@tvpeter Would really appreciate your feedback on this: #242 (comment)

It would help move this PR forward.

[tvpeter]

For this feature, how would you like it to be implemented? For example should we allow selecting a specific date or session to start pruning from? Or should it apply to all sessions older than a certain date? Alternatively should it target only expired or unsuccessful sessions?

I think it should apply to all sessions within a specific timeframe, say anything older than 30 days, and if it can be implemented without adding another command, that would be great. This can even go into another PR.

Also for the redb implementation most of the existing integrations have been built around SQLite so it made sense as the initial approach for this implementation. The Redb support may require some additional consideration and it would be good to align with the PayJoin team to ensure the approach is correct and consistent. Given that would you prefer the Redb implementation to be included in this PR or would it be acceptable to handle it in a follow-up?

That is still fine. It can form another PR, but it's one of the things you can consider adding.

It would also be helpful to understand what you consider a hard requirement for this PR versus what can be iterated on in subsequent changes.

The current implementation covering SQLite is good enough (and the most important). Those others can serve as improvements to the persistence feature.

[Mshehu5]

@va-an Thank you for the review. The reqwest issue is fixed in 7ee0a71. The regression was caused by a separate merged PR that updated reqwest without enabling rustls. I have verified the fix locally and it should be ready for you to retest on your end.

[notmandatory]

tACK bdb7f38

Thanks for the detailed test steps, very helpful for manual testing. I verified canceling receive and separately sender flow works as expected.

Any other feature enhancements such as using a DB transaction for atomic updates, or improved error types I recommend making new issues for. These sort of small improvements would be better made after #278 and in a future milestone. I also don't think we need this to support the redb persistence right now. If someone needs it they can implement it in a new PR.

[tvpeter]

@Mshehu5 pls rebase

[Mshehu5]

Description

#230 needed to be merged for this to go through
Address #149 also follow up to #200
This PR adds persistance to existing async payjoin integration
This introduces neccessary database model and tables also add commad for resume to allow interrupted sessions to be continued also a particular session either send or receive.
A history commad to view payjoin history and status has been added

Notes to the reviewers

Step to review this include making a payjoin transaction

Run a receiver to get a BIP21 URI then pass it to the sender as seen in docs

bdk-cli/README.md

Lines 121 to 141 in b9cf2ac

	To start a Payjoin session as the receiver with regtest RPC and example OHTTP relays:
	```
	cargo run --features rpc -- --network regtest wallet --wallet payjoin_wallet1 config --ext-descriptor "wpkh(tprv8ZgxMBicQKsPd2PoUEcGNDHPZmVWgtPYERAwMG6qHheX6LN4oaazp3qZU7mykiaAZga1ZB2SJJR6Mriyq8MocMs7QTe7toaabSwTWu5fRFz/84h/1h/0h/0/*)#8guqp7rn" --client-type rpc --database-type sqlite --url "127.0.0.1:18443"
	cargo run --features rpc -- wallet --wallet payjoin_wallet1 sync
	cargo run --features rpc -- wallet --wallet payjoin_wallet1 balance
	cargo run --features rpc -- wallet --wallet payjoin_wallet1 receive_payjoin --amount 400000 --max_fee_rate 1000 --directory "https://payjo.in" --ohttp_relay "https://pj.bobspacebkk.com" --ohttp_relay "https://pj.benalleng.com"
	```
	To send a Payjoin with regtest RPC and example OHTTP relays:
	```
	cargo run --features rpc -- --network regtest wallet --wallet payjoin_wallet2 config --ext-descriptor "wpkh(tprv8ZgxMBicQKsPfBxswkATvZRQ9kDdRbJPtHYZaZCARL2myxcK7DqsqPhRo2G2rRVHFPbowq63BE6S4k2pUMYeF2fUMTT63Q7zhoXtKsM1FaS/84'/1'/0'/0/*)#qf5gnqrf" --client-type rpc --database-type sqlite --url "127.0.0.1:18443"
	cargo run --features rpc -- wallet --wallet payjoin_wallet2 sync
	cargo run --features rpc -- wallet --wallet payjoin_wallet2 balance
	cargo run --features rpc -- wallet --wallet payjoin_wallet2 send_payjoin --ohttp_relay "https://pj.bobspacebkk.com" --ohttp_relay "https://pj.benalleng.com" --fee_rate 1 --uri "<URI>"
	```

To test resumption, interrupt either side with Ctrl+C mid-session then run resume on that side to continue. A few scenarios worth covering: receiver resuming after interrupt and sender resuming after interrupt. Use history after each scenario to confirm the session state was persisted correctly.

docs for this can be seen in 7e4ffd1

Checklists

All Submissions:

• I've signed all my commits
• I followed the contribution guidelines
• I ran cargo fmt and cargo clippy before committing

New Features:

• I've added docs for the new feature

[coveralls]

Pull Request Test Coverage Report for Build 22068931916

Details

• 0 of 763(0.0%) changed or added relevant lines in 5 files are covered.
• 5 unchanged lines in 3 files lost coverage.
• Overall coverage decreased (-1.9%) to 8.848%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/error.rs	0	21	0.0%
src/utils.rs	0	22	0.0%
src/handlers.rs	0	50	0.0%
src/payjoin/db.rs	0	262	0.0%
src/payjoin/mod.rs	0	408	0.0%

Files with Coverage Reduction	New Missed Lines	%
src/utils.rs	1	0.0%
src/handlers.rs	2	12.81%
src/payjoin/mod.rs	2	0.0%

Totals
Change from base Build 21153868360:	-1.9%
Covered Lines:	268
Relevant Lines:	3029

---

💛 - Coveralls

[tvpeter]

Thank you @Mshehu5 for working on this feature.

Below are some of the observations that I think will make the implementation better:

• I noticed that the implementation used only the sqlite db, and since sqlite is a db option in the project, I think it will be ideal if you also include implementation for redb db so users are free to choose any to use.
• The implementation does not provide for pruning/cleanup of data. Given that the db will tend to grow linearly and become sizable over time, I think it will be great to consider adding a pruning subcommand or mechanism that deletes irrelevant data.
• Since the save_event is generated at multiple transitions in a session, I think it will be great if you consider grouping such updates in a db transaction to ensure that entries are saved successfully.

I have also left some comments in the code.

Thank you.

[codecov]

Codecov Report

❌ Patch coverage is 68.46154% with 328 lines in your changes missing coverage. Please review.
✅ Project coverage is 28.87%. Comparing base (eea5ba9) to head (2f14a36).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
src/payjoin/mod.rs	26.21%	242 Missing ⚠️
src/handlers.rs	0.00%	33 Missing ⚠️
src/payjoin/db.rs	95.00%	30 Missing ⚠️
src/payjoin/ohttp.rs	73.33%	20 Missing ⚠️
src/error.rs	0.00%	3 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #242 +/- ##
===========================================
+ Coverage 11.36% 28.87% +17.51% 
===========================================
Files 8 9 +1 Lines 2807 3626 +819 ===========================================
+ Hits 319 1047 +728 - Misses 2488 2579 +91 

Flag	Coverage Δ
rust	28.87% <68.46%> (+17.51%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

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

[Mshehu5]

Thank you for the review!

Just wanted some clarifications

The implementation does not provide for pruning/cleanup of data. Given that the db will tend to grow linearly and become sizable over time, I think it will be great to consider adding a pruning subcommand or mechanism that deletes irrelevant data.

For this feature, how would you like it to be implemented? For example should we allow selecting a specific date or session to start pruning from? Or should it apply to all sessions older than a certain date? Alternatively should it target only expired or unsuccessful sessions?

I noticed that the implementation used only the sqlite db, and since sqlite is a db option in the project, I think it will be ideal if you also include implementation for redb db so users are free to choose any to use.

Also for the redb implementation most of the existing integrations have been built around SQLite so it made sense as the initial approach for this implementation. The Redb support may require some additional consideration and it would be good to align with the PayJoin team to ensure the approach is correct and consistent.
Given that would you prefer the Redb implementation to be included in this PR or would it be acceptable to handle it in a follow-up?

It would also be helpful to understand what you consider a hard requirement for this PR versus what can be iterated on in subsequent changes.

[vadim-anfv]

Hi @Mshehu5, thanks for this!

Could you update payjoin dependency to 1.0.0-rc.2 and run just pre-push?

I've got some errors from just pre-push like:

error[E0061]: this method takes 1 argument but 2 arguments were supplied
--> src/payjoin/mod.rs:691:30
|
691 | ... .check_payment(
| ^^^^^^^^^^^^^
...
704 | / ... |outpoint| {
705 || ... let utxo = self.wallet.get_utxo(outpoint);
706 || ... match utxo {
707 || ... Some(_) => Ok(false),
... |
710 || ... }
||___________________________- unexpected argument #2 of type `{closure@src/payjoin/mod.rs:704:33: 704:43}`

[Mshehu5]

@va-an Thanks for the review! I bumped Payjoin to 1.0.0-rc.2 and just pre-push passes locally. Mind giving it a try on your end? Would appreciate your feedback

[Mshehu5]

@tvpeter Would really appreciate your feedback on this: #242 (comment)

It would help move this PR forward.

[tvpeter]

For this feature, how would you like it to be implemented? For example should we allow selecting a specific date or session to start pruning from? Or should it apply to all sessions older than a certain date? Alternatively should it target only expired or unsuccessful sessions?

I think it should apply to all sessions within a specific timeframe, say anything older than 30 days, and if it can be implemented without adding another command, that would be great. This can even go into another PR.

Also for the redb implementation most of the existing integrations have been built around SQLite so it made sense as the initial approach for this implementation. The Redb support may require some additional consideration and it would be good to align with the PayJoin team to ensure the approach is correct and consistent. Given that would you prefer the Redb implementation to be included in this PR or would it be acceptable to handle it in a follow-up?

That is still fine. It can form another PR, but it's one of the things you can consider adding.

It would also be helpful to understand what you consider a hard requirement for this PR versus what can be iterated on in subsequent changes.

The current implementation covering SQLite is good enough (and the most important). Those others can serve as improvements to the persistence feature.

[Mshehu5]

@va-an Thank you for the review. The reqwest issue is fixed in 7ee0a71. The regression was caused by a separate merged PR that updated reqwest without enabling rustls. I have verified the fix locally and it should be ready for you to retest on your end.

[notmandatory]

tACK bdb7f38

Thanks for the detailed test steps, very helpful for manual testing. I verified canceling receive and separately sender flow works as expected.

Any other feature enhancements such as using a DB transaction for atomic updates, or improved error types I recommend making new issues for. These sort of small improvements would be better made after #278 and in a future milestone. I also don't think we need this to support the redb persistence right now. If someone needs it they can implement it in a new PR.

[tvpeter]

@Mshehu5 pls rebase

[Mshehu5]

Description

#230 needed to be merged for this to go through
Address #149 also follow up to #200
This PR adds persistance to existing async payjoin integration
This introduces neccessary database model and tables also add commad for resume to allow interrupted sessions to be continued also a particular session either send or receive.
A history commad to view payjoin history and status has been added

Notes to the reviewers

Step to review this include making a payjoin transaction

Run a receiver to get a BIP21 URI then pass it to the sender as seen in docs

bdk-cli/README.md

Lines 121 to 141 in b9cf2ac

	To start a Payjoin session as the receiver with regtest RPC and example OHTTP relays:
	```
	cargo run --features rpc -- --network regtest wallet --wallet payjoin_wallet1 config --ext-descriptor "wpkh(tprv8ZgxMBicQKsPd2PoUEcGNDHPZmVWgtPYERAwMG6qHheX6LN4oaazp3qZU7mykiaAZga1ZB2SJJR6Mriyq8MocMs7QTe7toaabSwTWu5fRFz/84h/1h/0h/0/*)#8guqp7rn" --client-type rpc --database-type sqlite --url "127.0.0.1:18443"
	cargo run --features rpc -- wallet --wallet payjoin_wallet1 sync
	cargo run --features rpc -- wallet --wallet payjoin_wallet1 balance
	cargo run --features rpc -- wallet --wallet payjoin_wallet1 receive_payjoin --amount 400000 --max_fee_rate 1000 --directory "https://payjo.in" --ohttp_relay "https://pj.bobspacebkk.com" --ohttp_relay "https://pj.benalleng.com"
	```
	To send a Payjoin with regtest RPC and example OHTTP relays:
	```
	cargo run --features rpc -- --network regtest wallet --wallet payjoin_wallet2 config --ext-descriptor "wpkh(tprv8ZgxMBicQKsPfBxswkATvZRQ9kDdRbJPtHYZaZCARL2myxcK7DqsqPhRo2G2rRVHFPbowq63BE6S4k2pUMYeF2fUMTT63Q7zhoXtKsM1FaS/84'/1'/0'/0/*)#qf5gnqrf" --client-type rpc --database-type sqlite --url "127.0.0.1:18443"
	cargo run --features rpc -- wallet --wallet payjoin_wallet2 sync
	cargo run --features rpc -- wallet --wallet payjoin_wallet2 balance
	cargo run --features rpc -- wallet --wallet payjoin_wallet2 send_payjoin --ohttp_relay "https://pj.bobspacebkk.com" --ohttp_relay "https://pj.benalleng.com" --fee_rate 1 --uri "<URI>"
	```

To test resumption, interrupt either side with Ctrl+C mid-session then run resume on that side to continue. A few scenarios worth covering: receiver resuming after interrupt and sender resuming after interrupt. Use history after each scenario to confirm the session state was persisted correctly.

docs for this can be seen in 7e4ffd1

Checklists

All Submissions:

• I've signed all my commits
• I followed the contribution guidelines
• I ran cargo fmt and cargo clippy before committing

New Features:

• I've added docs for the new feature

[coveralls]

Pull Request Test Coverage Report for Build 22068931916

Details

• 0 of 763(0.0%) changed or added relevant lines in 5 files are covered.
• 5 unchanged lines in 3 files lost coverage.
• Overall coverage decreased (-1.9%) to 8.848%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/error.rs	0	21	0.0%
src/utils.rs	0	22	0.0%
src/handlers.rs	0	50	0.0%
src/payjoin/db.rs	0	262	0.0%
src/payjoin/mod.rs	0	408	0.0%

Files with Coverage Reduction	New Missed Lines	%
src/utils.rs	1	0.0%
src/handlers.rs	2	12.81%
src/payjoin/mod.rs	2	0.0%

Totals
Change from base Build 21153868360:	-1.9%
Covered Lines:	268
Relevant Lines:	3029

---

💛 - Coveralls

[tvpeter]

Thank you @Mshehu5 for working on this feature.

Below are some of the observations that I think will make the implementation better:

• I noticed that the implementation used only the sqlite db, and since sqlite is a db option in the project, I think it will be ideal if you also include implementation for redb db so users are free to choose any to use.
• The implementation does not provide for pruning/cleanup of data. Given that the db will tend to grow linearly and become sizable over time, I think it will be great to consider adding a pruning subcommand or mechanism that deletes irrelevant data.
• Since the save_event is generated at multiple transitions in a session, I think it will be great if you consider grouping such updates in a db transaction to ensure that entries are saved successfully.

I have also left some comments in the code.

Thank you.

[codecov]

Codecov Report

❌ Patch coverage is 68.46154% with 328 lines in your changes missing coverage. Please review.
✅ Project coverage is 28.87%. Comparing base (eea5ba9) to head (2f14a36).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
src/payjoin/mod.rs	26.21%	242 Missing ⚠️
src/handlers.rs	0.00%	33 Missing ⚠️
src/payjoin/db.rs	95.00%	30 Missing ⚠️
src/payjoin/ohttp.rs	73.33%	20 Missing ⚠️
src/error.rs	0.00%	3 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #242 +/- ##
===========================================
+ Coverage 11.36% 28.87% +17.51% 
===========================================
Files 8 9 +1 Lines 2807 3626 +819 ===========================================
+ Hits 319 1047 +728 - Misses 2488 2579 +91 

Flag	Coverage Δ
rust	28.87% <68.46%> (+17.51%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

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

[Mshehu5]

Thank you for the review!

Just wanted some clarifications

The implementation does not provide for pruning/cleanup of data. Given that the db will tend to grow linearly and become sizable over time, I think it will be great to consider adding a pruning subcommand or mechanism that deletes irrelevant data.

For this feature, how would you like it to be implemented? For example should we allow selecting a specific date or session to start pruning from? Or should it apply to all sessions older than a certain date? Alternatively should it target only expired or unsuccessful sessions?

I noticed that the implementation used only the sqlite db, and since sqlite is a db option in the project, I think it will be ideal if you also include implementation for redb db so users are free to choose any to use.

Also for the redb implementation most of the existing integrations have been built around SQLite so it made sense as the initial approach for this implementation. The Redb support may require some additional consideration and it would be good to align with the PayJoin team to ensure the approach is correct and consistent.
Given that would you prefer the Redb implementation to be included in this PR or would it be acceptable to handle it in a follow-up?

It would also be helpful to understand what you consider a hard requirement for this PR versus what can be iterated on in subsequent changes.

[vadim-anfv]

Hi @Mshehu5, thanks for this!

Could you update payjoin dependency to 1.0.0-rc.2 and run just pre-push?

I've got some errors from just pre-push like:

error[E0061]: this method takes 1 argument but 2 arguments were supplied
--> src/payjoin/mod.rs:691:30
|
691 | ... .check_payment(
| ^^^^^^^^^^^^^
...
704 | / ... |outpoint| {
705 || ... let utxo = self.wallet.get_utxo(outpoint);
706 || ... match utxo {
707 || ... Some(_) => Ok(false),
... |
710 || ... }
||___________________________- unexpected argument #2 of type `{closure@src/payjoin/mod.rs:704:33: 704:43}`

[Mshehu5]

@va-an Thanks for the review! I bumped Payjoin to 1.0.0-rc.2 and just pre-push passes locally. Mind giving it a try on your end? Would appreciate your feedback

[Mshehu5]

@tvpeter Would really appreciate your feedback on this: #242 (comment)

It would help move this PR forward.

[tvpeter]

For this feature, how would you like it to be implemented? For example should we allow selecting a specific date or session to start pruning from? Or should it apply to all sessions older than a certain date? Alternatively should it target only expired or unsuccessful sessions?

I think it should apply to all sessions within a specific timeframe, say anything older than 30 days, and if it can be implemented without adding another command, that would be great. This can even go into another PR.

Also for the redb implementation most of the existing integrations have been built around SQLite so it made sense as the initial approach for this implementation. The Redb support may require some additional consideration and it would be good to align with the PayJoin team to ensure the approach is correct and consistent. Given that would you prefer the Redb implementation to be included in this PR or would it be acceptable to handle it in a follow-up?

That is still fine. It can form another PR, but it's one of the things you can consider adding.

It would also be helpful to understand what you consider a hard requirement for this PR versus what can be iterated on in subsequent changes.

The current implementation covering SQLite is good enough (and the most important). Those others can serve as improvements to the persistence feature.

[Mshehu5]

@va-an Thank you for the review. The reqwest issue is fixed in 7ee0a71. The regression was caused by a separate merged PR that updated reqwest without enabling rustls. I have verified the fix locally and it should be ready for you to retest on your end.

[notmandatory]

tACK bdb7f38

Thanks for the detailed test steps, very helpful for manual testing. I verified canceling receive and separately sender flow works as expected.

Any other feature enhancements such as using a DB transaction for atomic updates, or improved error types I recommend making new issues for. These sort of small improvements would be better made after #278 and in a future milestone. I also don't think we need this to support the redb persistence right now. If someone needs it they can implement it in a new PR.

[tvpeter]

@Mshehu5 pls rebase

[Mshehu5]

Description

#230 needed to be merged for this to go through
Address #149 also follow up to #200
This PR adds persistance to existing async payjoin integration
This introduces neccessary database model and tables also add commad for resume to allow interrupted sessions to be continued also a particular session either send or receive.
A history commad to view payjoin history and status has been added

Notes to the reviewers

Step to review this include making a payjoin transaction

Run a receiver to get a BIP21 URI then pass it to the sender as seen in docs

bdk-cli/README.md

Lines 121 to 141 in b9cf2ac

	To start a Payjoin session as the receiver with regtest RPC and example OHTTP relays:
	```
	cargo run --features rpc -- --network regtest wallet --wallet payjoin_wallet1 config --ext-descriptor "wpkh(tprv8ZgxMBicQKsPd2PoUEcGNDHPZmVWgtPYERAwMG6qHheX6LN4oaazp3qZU7mykiaAZga1ZB2SJJR6Mriyq8MocMs7QTe7toaabSwTWu5fRFz/84h/1h/0h/0/*)#8guqp7rn" --client-type rpc --database-type sqlite --url "127.0.0.1:18443"
	cargo run --features rpc -- wallet --wallet payjoin_wallet1 sync
	cargo run --features rpc -- wallet --wallet payjoin_wallet1 balance
	cargo run --features rpc -- wallet --wallet payjoin_wallet1 receive_payjoin --amount 400000 --max_fee_rate 1000 --directory "https://payjo.in" --ohttp_relay "https://pj.bobspacebkk.com" --ohttp_relay "https://pj.benalleng.com"
	```
	To send a Payjoin with regtest RPC and example OHTTP relays:
	```
	cargo run --features rpc -- --network regtest wallet --wallet payjoin_wallet2 config --ext-descriptor "wpkh(tprv8ZgxMBicQKsPfBxswkATvZRQ9kDdRbJPtHYZaZCARL2myxcK7DqsqPhRo2G2rRVHFPbowq63BE6S4k2pUMYeF2fUMTT63Q7zhoXtKsM1FaS/84'/1'/0'/0/*)#qf5gnqrf" --client-type rpc --database-type sqlite --url "127.0.0.1:18443"
	cargo run --features rpc -- wallet --wallet payjoin_wallet2 sync
	cargo run --features rpc -- wallet --wallet payjoin_wallet2 balance
	cargo run --features rpc -- wallet --wallet payjoin_wallet2 send_payjoin --ohttp_relay "https://pj.bobspacebkk.com" --ohttp_relay "https://pj.benalleng.com" --fee_rate 1 --uri "<URI>"
	```

To test resumption, interrupt either side with Ctrl+C mid-session then run resume on that side to continue. A few scenarios worth covering: receiver resuming after interrupt and sender resuming after interrupt. Use history after each scenario to confirm the session state was persisted correctly.

docs for this can be seen in 7e4ffd1

Checklists

All Submissions:

• I've signed all my commits
• I followed the contribution guidelines
• I ran cargo fmt and cargo clippy before committing

New Features:

• I've added docs for the new feature

[coveralls]

Pull Request Test Coverage Report for Build 22068931916

Details

• 0 of 763(0.0%) changed or added relevant lines in 5 files are covered.
• 5 unchanged lines in 3 files lost coverage.
• Overall coverage decreased (-1.9%) to 8.848%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/error.rs	0	21	0.0%
src/utils.rs	0	22	0.0%
src/handlers.rs	0	50	0.0%
src/payjoin/db.rs	0	262	0.0%
src/payjoin/mod.rs	0	408	0.0%

Files with Coverage Reduction	New Missed Lines	%
src/utils.rs	1	0.0%
src/handlers.rs	2	12.81%
src/payjoin/mod.rs	2	0.0%

Totals
Change from base Build 21153868360:	-1.9%
Covered Lines:	268
Relevant Lines:	3029

---

💛 - Coveralls

[tvpeter]

Thank you @Mshehu5 for working on this feature.

Below are some of the observations that I think will make the implementation better:

• I noticed that the implementation used only the sqlite db, and since sqlite is a db option in the project, I think it will be ideal if you also include implementation for redb db so users are free to choose any to use.
• The implementation does not provide for pruning/cleanup of data. Given that the db will tend to grow linearly and become sizable over time, I think it will be great to consider adding a pruning subcommand or mechanism that deletes irrelevant data.
• Since the save_event is generated at multiple transitions in a session, I think it will be great if you consider grouping such updates in a db transaction to ensure that entries are saved successfully.

I have also left some comments in the code.

Thank you.

[codecov]

Codecov Report

❌ Patch coverage is 68.46154% with 328 lines in your changes missing coverage. Please review.
✅ Project coverage is 28.87%. Comparing base (eea5ba9) to head (2f14a36).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
src/payjoin/mod.rs	26.21%	242 Missing ⚠️
src/handlers.rs	0.00%	33 Missing ⚠️
src/payjoin/db.rs	95.00%	30 Missing ⚠️
src/payjoin/ohttp.rs	73.33%	20 Missing ⚠️
src/error.rs	0.00%	3 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #242 +/- ##
===========================================
+ Coverage 11.36% 28.87% +17.51% 
===========================================
Files 8 9 +1 Lines 2807 3626 +819 ===========================================
+ Hits 319 1047 +728 - Misses 2488 2579 +91 

Flag	Coverage Δ
rust	28.87% <68.46%> (+17.51%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

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

[Mshehu5]

Thank you for the review!

Just wanted some clarifications

The implementation does not provide for pruning/cleanup of data. Given that the db will tend to grow linearly and become sizable over time, I think it will be great to consider adding a pruning subcommand or mechanism that deletes irrelevant data.

For this feature, how would you like it to be implemented? For example should we allow selecting a specific date or session to start pruning from? Or should it apply to all sessions older than a certain date? Alternatively should it target only expired or unsuccessful sessions?

I noticed that the implementation used only the sqlite db, and since sqlite is a db option in the project, I think it will be ideal if you also include implementation for redb db so users are free to choose any to use.

Also for the redb implementation most of the existing integrations have been built around SQLite so it made sense as the initial approach for this implementation. The Redb support may require some additional consideration and it would be good to align with the PayJoin team to ensure the approach is correct and consistent.
Given that would you prefer the Redb implementation to be included in this PR or would it be acceptable to handle it in a follow-up?

It would also be helpful to understand what you consider a hard requirement for this PR versus what can be iterated on in subsequent changes.

[vadim-anfv]

Hi @Mshehu5, thanks for this!

Could you update payjoin dependency to 1.0.0-rc.2 and run just pre-push?

I've got some errors from just pre-push like:

error[E0061]: this method takes 1 argument but 2 arguments were supplied
--> src/payjoin/mod.rs:691:30
|
691 | ... .check_payment(
| ^^^^^^^^^^^^^
...
704 | / ... |outpoint| {
705 || ... let utxo = self.wallet.get_utxo(outpoint);
706 || ... match utxo {
707 || ... Some(_) => Ok(false),
... |
710 || ... }
||___________________________- unexpected argument #2 of type `{closure@src/payjoin/mod.rs:704:33: 704:43}`

[Mshehu5]

@va-an Thanks for the review! I bumped Payjoin to 1.0.0-rc.2 and just pre-push passes locally. Mind giving it a try on your end? Would appreciate your feedback

[Mshehu5]

@tvpeter Would really appreciate your feedback on this: #242 (comment)

It would help move this PR forward.

[tvpeter]

For this feature, how would you like it to be implemented? For example should we allow selecting a specific date or session to start pruning from? Or should it apply to all sessions older than a certain date? Alternatively should it target only expired or unsuccessful sessions?

I think it should apply to all sessions within a specific timeframe, say anything older than 30 days, and if it can be implemented without adding another command, that would be great. This can even go into another PR.

Also for the redb implementation most of the existing integrations have been built around SQLite so it made sense as the initial approach for this implementation. The Redb support may require some additional consideration and it would be good to align with the PayJoin team to ensure the approach is correct and consistent. Given that would you prefer the Redb implementation to be included in this PR or would it be acceptable to handle it in a follow-up?

That is still fine. It can form another PR, but it's one of the things you can consider adding.

It would also be helpful to understand what you consider a hard requirement for this PR versus what can be iterated on in subsequent changes.

The current implementation covering SQLite is good enough (and the most important). Those others can serve as improvements to the persistence feature.

[Mshehu5]

@va-an Thank you for the review. The reqwest issue is fixed in 7ee0a71. The regression was caused by a separate merged PR that updated reqwest without enabling rustls. I have verified the fix locally and it should be ready for you to retest on your end.

[notmandatory]

tACK bdb7f38

Thanks for the detailed test steps, very helpful for manual testing. I verified canceling receive and separately sender flow works as expected.

Any other feature enhancements such as using a DB transaction for atomic updates, or improved error types I recommend making new issues for. These sort of small improvements would be better made after #278 and in a future milestone. I also don't think we need this to support the redb persistence right now. If someone needs it they can implement it in a new PR.

[tvpeter]

@Mshehu5 pls rebase