Reporting Mode: Attempting to retrieve pseudotransaction with "tx" returns "txnNotFound" (Version: 1.8.5)

[intelliot]

Reported by: @natenichols @ckniffen

Issue Description

When attempting to retrieve a pseudo-transaction from a full history Reporting Mode server, rippled returns "txnNotFound".

Steps to Reproduce

Example: Amendment fixPayChanRecipientOwnerDir with key D2F8E457D08ACB185CDE3BB9BB1989A9052344678566785BACFB9DFDBDEDCF09

{ "method": "tx", "transaction": "D2F8E457D08ACB185CDE3BB9BB1989A9052344678566785BACFB9DFDBDEDCF09" }

When I request this with transaction_entry, the transaction is in fact there. (using the tx hash and the ledger index)

When looking up the ledger that the tx is in, the tx doesn't appear there either: https://xrpl.org/websocket-api-tool.html?server=wss%3A%2F%2Fs1.ripple.com%2F&req=%7B%22id%22%3A14%2C%22command%22%3A%22ledger%22%2C%22ledger_index%22%3A%2255161089%22%2C%22full%22%3Afalse%2C%22accounts%22%3Afalse%2C%22transactions%22%3Atrue%2C%22expand%22%3Afalse%2C%22owner_funds%22%3Afalse%7D

(When we look up other transactions from the same ledger, 55161089, "tx" finds them just fine.)

The pseudotransaction:

• Does NOT show up on the Livenet Explorer https://livenet.xrpl.org/ledgers/55161089
• DOES show up on XRPSCAN https://xrpscan.com/ledger/55161089 / https://xrpscan.com/tx/D2F8E457D08ACB185CDE3BB9BB1989A9052344678566785BACFB9DFDBDEDCF09

Expected Result

Pseudotransaction details in response

Actual Result

txnNotFound

Environment

rippled Reporting Mode (s1/s2.ripple.com)

Note: xrplcluster is not affected since those are p2p FH nodes (not Reporting Mode)

Note: Some newer amendment pseudotransactions are retrievable, so not all are affected.

[cjcobb23]

@natenichols does this affect all reporting mode servers? Or just some?

[mDuo13]

I (re-)opened #2597 for this issue. The OP there has some test cases that seem to work.

(Also, confirming that this still applies to v1.10.1)

[intelliot]

Example: https://livenet.xrpl.org/transactions/97FD0E35654F4B6714010D3CBBAC4038F60D64AD0292693C28A1DF4B796D8469

Appears to affect all reporting mode servers.

[intelliot]

@injaelee @mounikakun can we check whether this problem occurs in Clio?