Add queues to track the need for transaction enhancement and/or verification of mined status.#1473
Conversation
7709120 to
9e22493
Compare
ecee800 to
8749d37
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1473 +/- ##
==========================================
+ Coverage 60.82% 61.16% +0.34%
==========================================
Files 140 141 +1
Lines 16472 16650 +178
==========================================
+ Hits 10019 10184 +165
- Misses 6453 6466 +13 ☔ View full report in Codecov by Sentry. |
d3837d4 to
9ffcb8e
Compare
7994e82 to
cc3c34f
Compare
93d75b0 to
1cbced3
Compare
1cbced3 to
4741662
Compare
request in `set_transaction_status`. Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
…nsfer`. fixes zcash#1485 Signed-off-by: Daira-Emma Hopwood <daira@jacaranda.org>
| // In order to have made a Status request, we must already have had the | ||
| // raw transaction (the only callers of `queue_tx_retrieval` are in contexts | ||
| // where we must have already called `put_tx_data`). Therefore, it is safe | ||
| // to unconditionally delete the request from `tx_retrieval_queue` below | ||
| // (both in the expired case and the case where it has been mined), because | ||
| // we already have all the data we need about this transaction. |
There was a problem hiding this comment.
This is true for Status requests, but not true for Enhancement requests which subsume Status.
There was a problem hiding this comment.
Yes. I noticed that and the first commit of nuttycom#39 (nuttycom@239f7ff) fixes it. The implementation is fine, it's just the comment that is incorrect.
There was a problem hiding this comment.
It occurs to me that https://github.com/zcash/librustzcash/pull/1473/files#diff-a1724f7547ecabc613a07520eaf7917d9084d4277219d186698b0c8e352495a4R2425-R2427 is superfluous; we should never have a Status request for a transaction unless we have the raw data. So one way to fix this would be to remove the query type argument from the queue_tx_retrieval function, and to set it based upon the presence or absence of raw transaction data.
There was a problem hiding this comment.
The comment change doesn't resolve my concern. GetStatus is indeed only generated when we have the raw transaction (as I noted), but Enhancement is generated by definition when we don't have the raw transaction, and its documentation states that when the caller is unable to look up the transaction, it must call this method.
The reason it is okay to delete for Enhancement requests is that:
- If a transaction can't be enhanced, we assume that the caller calls this method with
TransactionStatus::TxidNotRecognized(as the other two statuses mean that the chain data source knew about the transaction, and therefore must have observed it and could return its raw data), so we don't need to consider what happens in the other statuses. - We only delete for
TransactionStatus::TxidNotRecognizedif the transaction is expired, at which point we don't necessarily care about enhancement (though the user might still care about the memo), and it is very likely that we will be unable to ever enhance (as the tx will have been dropped from all mempools).
There was a problem hiding this comment.
The fact is that an Enhancement request is a Status request. That's what it means for an Enhancement request to subsume a Status request. It's either "get me the status" or "get me the status and the data if it's available".
There was a problem hiding this comment.
@daira Enhancement is getting the status; it subsumes / is a superset of GetStatus. That's why I raised my initial concern that this method was being written ostensibly assuming it would only be called via GetStatus, which was false.
As @nuttycom says, the actual implementation does correctly work with both GetStatus and Enhancement; the comment was just misleading.
There was a problem hiding this comment.
I have now updated this comment again. (b47c7bf)
There was a problem hiding this comment.
The fact is that an Enhancement request is a Status request.
Not so. Otherwise it wouldn't have to requeue a Status request when queue_status_retrieval is true. It doesn't directly update the mined height in the case where d_tx.mined_height().is_none().
There was a problem hiding this comment.
Otherwise it wouldn't have to requeue a Status request when queue_status_retrieval is true.
The re-queueing is so that the wallet continues to monitor for when the transaction is eventually mined. A relevant case here is that store_decrypted_tx was called with a transaction that was read from the mempool; we have complete transaction data, but we don't know yet whether the transaction will be mined, so we stick the status request back on the queue. For a fully transparent transaction that we get from the mempool we have no other way of detecting that it becomes mined.
There was a problem hiding this comment.
utACK modulo suggested changes in nuttycom#39 . We can either merge that PR into this one, or merge a copy of it separately. (I have checked that it passes tests locally.)
…o wallet/enrichment_queue
…14868de..d978256a2 d978256a2 Merge pull request #1 from zcash/compact_tx_transparent 7eeb82e7c Merge pull request #4 from zcash/add_changelog a95359dc9 Apply suggestions from code review 592b637a8 Add transparent data to the `CompactBlock` format. 9d1fb2c41 Add a CHANGELOG.md that documents the evolution of the light client protocol. 180717dfa Merge pull request #3 from zcash/merge_librustzcash_history 450bd4181 Merge the history of the .proto files from `librustzcash` for complete history preservation. a4859d11d Move protobuf files into place for use in `zcash/lightwallet-protocol` 2e66cdd9e Update zcash_client_backend/proto/service.proto eda012519 fix comment f838d10ad Add gRPC LightdInfo Donation Address db12c0415 Merge pull request #1473 from nuttycom/wallet/enrichment_queue 698feba96 Apply suggestions from code review 20ce57ab3 zcash_client_backend: Add `block_height` argument to `decrypt_and_store_transaction` a6dea1da8 Merge pull request #1482 from zancas/doc_tweak 4d2d45fc9 fix incorrect doc-comment e826f4740 update CompactBlock doc-comment, to cover non-Sapling shielded notes, and addresses e9a6c00bf Various documentation improvements 988bc7214 Merge pull request #872 from nuttycom/feature/pre_dag_sync-suggest_scan_ranges 58d07d469 Implement `suggest_scan_ranges` and `update_chain_tip` a9222b338 Address comments from code review. e20310857 Rename proto::compact::{BlockMetadata => ChainMetadata} ac63418c5 Reorganize Sapling and Orchard note commitment tree sizes in CompactBlock. 0fdca14f1 zcash_client_backend: Add note commitment tree sizes to `CompactBlock` serialization. 2a0c2b8b7 zcash_client_backend: Add gRPC bindings behind feature flag 1342f0480 zcash_client_backend: Address compact_formats.proto comments 68aa4e01b zcash_client_backend: Bring in latest `compact_formats.proto` e712eb1bc Add prevHash field to CompactBlock 440384c3e Build protobufs for compact formats git-subtree-dir: zcash_client_backend/lightwallet-protocol git-subtree-split: d978256a2bf33bb5f83846d8994e7377512f5f05
…14868de..23f0768ea 23f0768ea Release lightwallet-protocol v0.4.0 41156c767 Merge pull request #11 from zcash/feature/get_mempool_tx_pools 7c130e883 Add `lightwalletProtocolVersion` field to `LightdInfo` struct. edbb726d7 Apply suggestion from code review 38fddd73b Apply suggestions from code review 0250f2720 Add pool type filtering to `GetMempoolTx` argument. 54ccaadd5 Change semantics of pool-based pruning of compact transactions from "may prune" to "must prune". b0667ec99 Merge pull request #9 from zcash/2025-11-doc-TransparentAddressBlockFilter f3fea7bd4 doc: TransparentAddressBlockFilter doesn't include mempool a67dd323a Merge pull request #8 from zcash/2025-11-lightdinfo-upgrade-info 11da4b7e3 add next upgrade info to LightdInfo structure (GetLightdInfo) 42cd8f720 Transparent data docs update (#7) c0cf957ac Merge pull request #5 from zcash/2025-11-comments 912fc3609 Minor clarification in GetBlockRange documentation. 6b03f2cce Documentation (comments) only d978256a2 Merge pull request #1 from zcash/compact_tx_transparent 7eeb82e7c Merge pull request #4 from zcash/add_changelog a95359dc9 Apply suggestions from code review 592b637a8 Add transparent data to the `CompactBlock` format. 9d1fb2c41 Add a CHANGELOG.md that documents the evolution of the light client protocol. 180717dfa Merge pull request #3 from zcash/merge_librustzcash_history 450bd4181 Merge the history of the .proto files from `librustzcash` for complete history preservation. a4859d11d Move protobuf files into place for use in `zcash/lightwallet-protocol` 2e66cdd9e Update zcash_client_backend/proto/service.proto eda012519 fix comment f838d10ad Add gRPC LightdInfo Donation Address db12c0415 Merge pull request #1473 from nuttycom/wallet/enrichment_queue 698feba96 Apply suggestions from code review 20ce57ab3 zcash_client_backend: Add `block_height` argument to `decrypt_and_store_transaction` a6dea1da8 Merge pull request #1482 from zancas/doc_tweak 4d2d45fc9 fix incorrect doc-comment e826f4740 update CompactBlock doc-comment, to cover non-Sapling shielded notes, and addresses e9a6c00bf Various documentation improvements 988bc7214 Merge pull request #872 from nuttycom/feature/pre_dag_sync-suggest_scan_ranges 58d07d469 Implement `suggest_scan_ranges` and `update_chain_tip` a9222b338 Address comments from code review. e20310857 Rename proto::compact::{BlockMetadata => ChainMetadata} ac63418c5 Reorganize Sapling and Orchard note commitment tree sizes in CompactBlock. 0fdca14f1 zcash_client_backend: Add note commitment tree sizes to `CompactBlock` serialization. 2a0c2b8b7 zcash_client_backend: Add gRPC bindings behind feature flag 1342f0480 zcash_client_backend: Address compact_formats.proto comments 68aa4e01b zcash_client_backend: Bring in latest `compact_formats.proto` e712eb1bc Add prevHash field to CompactBlock 440384c3e Build protobufs for compact formats git-subtree-dir: zcash_client_backend/lightwallet-protocol git-subtree-split: 23f0768ea4471b63285f3c0e9b6fbb361674aa2b
No description provided.