receiptQueue (kept upstream, not revived)¶
| Source (upstream v1.17.4) | Current | |
|---|---|---|
| File | eth/downloader/fetchers_concurrent_receipts.go |
fetchers_concurrent_receipts.go |
| Symbol | receiptQueue |
receiptQueue |
| Ref | v1.17.4 |
etc/v1.17.4-full-node |
Kept on upstream v1.17.4 unchanged. Rationale: upstream v1.17.4 stores block receipts in the downloader as storage-RLP (fetchResult.Receipts is rlp.RawValue, bloom-less), and queue.DeliverReceipts / InsertReceiptChain were rewritten around that shape. Pre-purge instead carried decoded []types.Receipt structs all the way to InsertReceiptChain, which did the storage encoding. Reverting to the pre-purge shape would mean reverting fetchResult.Receipts + DeliverReceipts + the rewritten InsertReceiptChain (all CORE, non-_pow files) — far MORE divergence from the v1.17.4 base than it removes, and lasting rebase cost. The only pre-purge-facing surface that matters for network compatibility is the wire encoding, and that IS revived byte-exact (handleGetReceipts68 / ServiceGetReceiptsQuery68 / handleReceipts68 / ReceiptsPacket68 / ReplyReceiptsRLP). The network->storage conversion still happens — handleReceipts68 does it via ReceiptList68.EncodeForStorage, the exact counterpart of the eth/69 path's dispatchReceipts -> ReceiptList.EncodeForStorage — it simply lives at the handler layer (where v1.17.4 put it) instead of inside InsertReceiptChain (where pre-purge put it). See the handleReceipts68 entry for the per-function detail.
No differences found — identical to source (or rename-only).