Transaction Query

Overview

A Transaction Query retrieves known information about a blockchain transaction using a hash, account, block, or provider-specific identifier. It differs from a receipt query because a transaction object and its execution receipt expose different information and can become available at different times.

The main risks include querying the wrong chain, interpreting null as permanent failure, stale provider indexes, replaced transactions, and early acceptance as final. It may return pending status, block inclusion, sender, recipient, value, fee fields, and execution data.

In production, teams should define ownership and apply canonical identifiers, pending and null handling, chain verification, provider comparison, reorganization handling, and confirmation tracking. For Transaction Query, identifiers and timestamps should remain stable enough to trace the technical action to its final business outcome.

Useful measures include query success rate, unknown transaction count, provider divergence, time to visibility, and reorganization corrections. Transaction Query is closely connected to Receipt Query, Transaction Broadcast, and RPC Timeout. The Transaction Query runbook should define who can retry, cancel, replay, reconcile, communicate, and approve an exception.

Monitoring for Transaction Query should distinguish transport success, processing success, and the final external or financial result. Changes to Transaction Query should be tested against normal, failed, delayed, duplicate, and recovery paths that apply to the operation.

Evidence for Transaction Query should preserve the input, configuration version, actor or service, decision, downstream reference, and final outcome. Testing Transaction Query should cover boundary values, dependency failure, restart recovery, and incompatible versions where they affect the workflow. Operational metrics for Transaction Query should use stable denominators and separate technical activity from successful business completion.