Replace the put_tx_meta workaround in `send_multi_step_proposed_tra…

…nsfer`.

fixes #1485

Signed-off-by: Daira-Emma Hopwood <[email protected]>

zcash_client_sqlite/src/testing/pool.rs

@@ -306,9 +306,9 @@ pub(crate) fn send_multi_step_proposed_transfer<T: ShieldedPoolTester>() {
 
     use rand_core::OsRng;
     use zcash_client_backend::{
-        data_api::TransactionDataRequest,
+        data_api::{TransactionDataRequest, TransactionStatus},
         fees::ChangeValue,
-        wallet::{TransparentAddressMetadata, WalletTx},
+        wallet::TransparentAddressMetadata,
     };
     use zcash_primitives::{
         legacy::keys::{NonHardenedChildIndex, TransparentKeyScope},
@@ -683,40 +683,25 @@ pub(crate) fn send_multi_step_proposed_transfer<T: ShieldedPoolTester>() {
     let (h, _) = st.generate_next_block_from_tx(tx_index, tx);
     st.scan_cached_blocks(h, 1);
 
-    // The rest of this test would currently fail without the explicit call to
-    // `put_tx_meta` below. Ideally the above `scan_cached_blocks` would be
-    // sufficient, but it does not detect the transaction as interesting to the
+    // The above `scan_cached_blocks` does not detect `tx` as interesting to the
     // wallet. If a transaction is in the database with a null `mined_height`,
     // as in this case, its `mined_height` will remain null unless `put_tx_meta`
-    // is called on it. Normally `put_tx_meta` would be called via `put_blocks`
-    // as a result of scanning, but that won't happen for any fully transparent
-    // transaction, and currently it also will not happen for a partially shielded
-    // transaction unless it is interesting to the wallet for another reason.
-    // Therefore we will not currently detect either collisions with uses of
-    // ephemeral outputs by other wallets, or refunds of funds sent to TEX
-    // addresses. (#1354, #1379)
-
-    // Check that what we say in the above paragraph remains true, so that we
-    // don't accidentally fix it without updating this test.
+    // is called on it. This happens either via `put_blocks` as a result of
+    // scanning, or via `set_transaction_status` in response to processing the
+    // `transaction_data_requests` queue. For a fully transparent transaction,
+    // the latter is required.
+
+    // The reservation should fail because `tx` is not yet seen as mined.
     reservation_should_fail(&mut st, 1, 22);
 
-    // For now, we demonstrate that this problem is the only obstacle to the rest
-    // of the ZIP 320 code doing the right thing, by manually calling `put_tx_meta`:
-    crate::wallet::put_tx_meta(
-        &st.wallet_mut().conn,
-        &WalletTx::new(
-            tx.txid(),
-            tx_index,
-            vec![],
-            vec![],
-            #[cfg(feature = "orchard")]
-            vec![],
-            #[cfg(feature = "orchard")]
-            vec![],
-        ),
-        h,
-    )
-    .unwrap();
+    // Simulate the wallet processing the `transaction_data_requests` queue.
+    let tx_data_requests = st.wallet().transaction_data_requests().unwrap();
+    assert!(tx_data_requests.contains(&TransactionDataRequest::GetStatus(tx.txid())));
+
+    // Respond to the GetStatus request.
+    st.wallet_mut()
+        .set_transaction_status(tx.txid(), TransactionStatus::Mined(h))
+        .unwrap();
 
     // We already reserved 22 addresses, so mining the transaction with the
     // ephemeral output at index 10 should allow 9 more (..31).