What happened?
https://github.com/ZcashFoundation/zebra/actions/runs/33644944705/job/100303430541
Claude diagnostic:
It's a byte-order mismatch introduced by the lightwalletd v0.4.17 → v0.5.3 bump (your commit 3eed90c, 2026-08-21), not a Zebra regression.
The failure is at zebrad/tests/common/lightwalletd/send_transaction_test.rs:307:
unexpected transaction transaction::Hash("820f1e8b…f7f9b432")
in isolated mempool: CompactTx { index: 0, hash: [130, 15, 30, 139, …] }
That hash reversed is 32b4f9f7…8b1e0f82 — one of the transactions the test itself sent a second earlier ("sending transaction… 32b4f9f7…"). So the transaction did reach the mempool; the test just decoded its
txid backwards.
Why the bump changed it. Both lwd versions build CompactTx with tx.GetEncodableHash() (documented as little-endian), but in v0.4.17's GetMempoolTx the txid was set straight from the display-order hex of
getrawmempool:
txidBytes, _ := hex.DecodeString(txidstr) // big-endian / display order
tx.SetTxID(txidBytes) // stored as-is → emitted in display order
v0.5.3 fixed that inconsistency (frontend/service.go:820):
// convert from big endian bytes to little endian and set as the txid
tx.SetTxID(hash32.Reverse(hash32.FromSlice(txidBigEndian)))
So the mempool txid is now little-endian, like everywhere else. The test still does transaction::Hash::from_bytes_in_display_order(&hash), which reverses again, and the transaction_hashes.contains(&hash)
assert fails on the first streamed tx.
What were you doing when the issue happened?
No response
Zebra logs
No response
Zebra Version
No response
Which operating systems does the issue happen on?
OS details
No response
Additional information
No response
What happened?
https://github.com/ZcashFoundation/zebra/actions/runs/33644944705/job/100303430541
Claude diagnostic:
It's a byte-order mismatch introduced by the lightwalletd v0.4.17 → v0.5.3 bump (your commit 3eed90c, 2026-08-21), not a Zebra regression.
The failure is at zebrad/tests/common/lightwalletd/send_transaction_test.rs:307:
unexpected transaction transaction::Hash("820f1e8b…f7f9b432")
in isolated mempool: CompactTx { index: 0, hash: [130, 15, 30, 139, …] }
That hash reversed is 32b4f9f7…8b1e0f82 — one of the transactions the test itself sent a second earlier ("sending transaction… 32b4f9f7…"). So the transaction did reach the mempool; the test just decoded its
txid backwards.
Why the bump changed it. Both lwd versions build CompactTx with tx.GetEncodableHash() (documented as little-endian), but in v0.4.17's GetMempoolTx the txid was set straight from the display-order hex of
getrawmempool:
txidBytes, _ := hex.DecodeString(txidstr) // big-endian / display order
tx.SetTxID(txidBytes) // stored as-is → emitted in display order
v0.5.3 fixed that inconsistency (frontend/service.go:820):
// convert from big endian bytes to little endian and set as the txid
tx.SetTxID(hash32.Reverse(hash32.FromSlice(txidBigEndian)))
So the mempool txid is now little-endian, like everywhere else. The test still does transaction::Hash::from_bytes_in_display_order(&hash), which reverses again, and the transaction_hashes.contains(&hash)
assert fails on the first streamed tx.
What were you doing when the issue happened?
No response
Zebra logs
No response
Zebra Version
No response
Which operating systems does the issue happen on?
OS details
No response
Additional information
No response