Closed aasseman closed 11 months ago
🤖 Cargo Audit Report 🤖
(Empty means OK! 👍)
Changes Missing Coverage | Covered Lines | Changed/Added Lines | % | ||
---|---|---|---|---|---|
tap_core/src/tap_receipt/receipt_auditor.rs | 102 | 105 | 97.14% | ||
<!-- | Total: | 125 | 128 | 97.66% | --> |
Totals | |
---|---|
Change from base Build 6500762705: | 2.1% |
Covered Lines: | 1231 |
Relevant Lines: | 1498 |
🤖 Cargo Audit Report 🤖
(Empty means OK! 👍)
What do you think about proxying the batch call through received receipts class? That way, we can ensure the state remains owned by received receipt. I am worried that we will get difficult bugs popping up as soon as we start requiring the state to be managed outside the state owner. I think the code would look something like this:
impl ReceivedReceipt {
...
pub async fn perform_batch_checks<CA: EscrowAdapter, RCA: ReceiptChecksAdapter>(
batch: &mut [Self],
check: &ReceiptCheck,
receipt_auditor: &ReceiptAuditor<CA, RCA>,
) -> crate::Result<()> {
receipt_auditor
.check_batch(check, batch)
.await?;
for receipt in batch {
receipt.update_state();
}
Ok(())
}
...
}
Additionally, we could return the list of results and have ReceivedReceipt do the updating as well, mainly to keep the approach consistent.
pub async fn perform_batch_checks<CA: EscrowAdapter, RCA: ReceiptChecksAdapter>(
batch: &mut [Self],
check: &ReceiptCheck,
receipt_auditor: &ReceiptAuditor<CA, RCA>,
) -> crate::Result<()> {
results = receipt_auditor
.check_batch(check, batch)
.await?;
for (receipt,result) in batch.iter_mut().zip(results) {
receipt.update_check(check, result);
receipt.update_state();
}
ok(())
}
Assuming the returned list of results are in the same order as the receipts provided. (edited)
I reverted a commit that shouldn't be in this PR, and applied your suggestion.
🤖 Cargo Audit Report 🤖
(Empty means OK! 👍)
🤖 Cargo Audit Report 🤖
(Empty means OK! 👍)
The checks are specifically made to check the receipts that are to be aggregated only in their own context. Helps for uniqueness checks for example, where we avoid calling the storage backend and only check that the collected receipts are unique.
In terms of the public API, this should be a cleaner solution than #179 . The implementation itself is not super clean though. A deeper refactor of tap_core may help make this a bit less hacky.