Not a bug, this matches standard Solana JSON-RPC semantics exactly (mainline getSignatureStatuses also requires this flag to look beyond a short-lived recent-status cache). Filing as a docs clarification since it wasn't obvious from crates/superbank-rpc/README.md's method list.
Observed behavior: calling getSignatureStatuses with a real, indexed signature (confirmed present in the signatures table) returns null:
{"jsonrpc":"2.0","id":1,"result":{"context":{"slot":...},"value":[null]}}
Adding {"searchTransactionHistory": true} as the second param returns the full status correctly.
Suggested fix: add a line to the method list in crates/superbank-rpc/README.md noting this requirement, since a new integrator (especially one coming from a different RPC provider) could reasonably assume a signature that's known to exist would resolve without needing this flag.
Not a bug, this matches standard Solana JSON-RPC semantics exactly (mainline getSignatureStatuses also requires this flag to look beyond a short-lived recent-status cache). Filing as a docs clarification since it wasn't obvious from crates/superbank-rpc/README.md's method list.
Observed behavior: calling getSignatureStatuses with a real, indexed signature (confirmed present in the signatures table) returns null:
{"jsonrpc":"2.0","id":1,"result":{"context":{"slot":...},"value":[null]}}
Adding {"searchTransactionHistory": true} as the second param returns the full status correctly.
Suggested fix: add a line to the method list in crates/superbank-rpc/README.md noting this requirement, since a new integrator (especially one coming from a different RPC provider) could reasonably assume a signature that's known to exist would resolve without needing this flag.