Documentation
¶
Overview ¶
Package rpc waits for a submitted Stellar transaction to be applied to the ledger.
Submitting a transaction only returns an acceptance status; the network applies it a few ledgers later. PollTransaction bridges that gap: it fetches the transaction by hash on an interval until it reaches a terminal state, then reports the outcome. NOT_FOUND means not yet applied and is retried; a transient fetch error is also retried; SUCCESS and FAILED are terminal. The poll ends in failure if the context is cancelled, the attempt budget is exhausted (timeout), or the status is unrecognized.
TransactionGetter is the one-method interface PollTransaction depends on, so any RPC client — or a mock — can drive it. PollConfig sets the attempt budget, interval, and logger; DefaultPollConfig supplies sensible values that callers override as needed.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func PollTransaction ¶
func PollTransaction( ctx context.Context, client TransactionGetter, txHash string, cfg PollConfig, ) (protocol.GetTransactionResponse, error)
PollTransaction polls for transaction completion with proper logging. It returns the full GetTransactionResponse on success and any error encountered.
Types ¶
type Payment ¶ added in v1.0.0
Payment is a classic payment operation extracted from a transaction envelope.
type PollConfig ¶
PollConfig configures the polling behavior
func DefaultPollConfig ¶
func DefaultPollConfig() PollConfig
DefaultPollConfig returns the default polling configuration
type TransactionGetter ¶
type TransactionGetter interface {
GetTransaction(ctx context.Context, req protocol.GetTransactionRequest) (protocol.GetTransactionResponse, error)
}
TransactionGetter is the interface for fetching transaction status
type Verifier ¶ added in v1.0.0
type Verifier struct {
// contains filtered or unexported fields
}
Verifier confirms the on-ledger outcome of a transaction someone else claims to have submitted — an anchor reporting a refund, for example.
Unlike PollTransaction it does not wait: a single lookup either answers definitively or reports the outcome as unknown, leaving the retry cadence to the caller.
func NewVerifier ¶ added in v1.0.0
func NewVerifier(client TransactionGetter) *Verifier
NewVerifier returns a Verifier backed by the given RPC client.
func (*Verifier) PaymentsTo ¶ added in v1.0.0
func (v *Verifier) PaymentsTo(ctx context.Context, txHash, destination, assetCode, assetIssuer string) ([]Payment, error)
PaymentsTo returns the successful payments in txHash addressed to destination, in the named asset.
assetIssuer, when non-empty, must also match. Asset codes are not unique — anyone can issue an asset called USDC — so matching on code alone would let a worthless look-alike settle a refund.
This exists because "the transaction succeeded" is not the question worth asking about an anchor's claimed refund — our own outbound payment to that anchor also succeeded. What matters is that value moved in the right direction, in the right asset, and how much. Reading it from the ledger means a mislabelled or misread anchor field cannot drive a vault repay.
Returns an error unless the transaction is on-ledger and succeeded.
func (*Verifier) TransactionSucceeded ¶ added in v1.0.0
TransactionSucceeded reports whether txHash succeeded on-ledger.
The three outcomes are distinct and callers must treat them differently:
- (true, nil) the transaction is on the ledger and succeeded
- (false, nil) it is on the ledger and definitively failed
- (false, err) unknown — not yet visible, outside the RPC's retention window, or the lookup itself failed
An unknown result is never a failure. Soroban RPC only retains recent transactions, so a hash older than the retention window reports NOT_FOUND indefinitely; callers that retry forever on error should bound their retries or escalate to a human.
Source Files