views: zero-copy XDR view extractors — events, tx-hashes, tx-details, tx-pages (#764) - #778

Doesn't this more-or-less just re-marshal it anyway? It's a little more involved than that and obviously the code would be really gross but the round trip here does feelsbadman a bit.

Alternatively, since you're already unmarshaling the envelope, you can remove the code above that fetches type via views and just do it the "normal" way for brevity.

Done below.

Closing the loop: the decode is gone entirely now — the hash preimage is built from the wire bytes directly (da9ee15), so neither the decode nor the round-trip exists anymore.

There's also TransactionMeta"V0" which is just the Operations *[]OperationMeta field being filled out which doesn't appear to be considered here

I had that question too but it seems like current RPC doesn't support V0

- db.ParseTransaction → ingestTx.GetTransactionEvents() → SDK ledger_transaction.go:308 has a default:
  that returns "unsupported TransactionMeta version: 0".

Hmm but I guess so with this implementation of rpc v2 we should?

Oh I see. I remember one other thing. Full history rpc v2 would realistically never have V0 txmeta because it would ingest with the unified events and backfill flags set to true cause otherwise there wouldn't be any events for classic

Anyhoo I'm forcing claude to add it in

Yeah current RPC doesn't need to support it because it'd never come up, but with full history it's possible. You're 100% right about the flags, though - but better to be defensive!

There's gooooootta be a better way to do this than per-property error inspection.... It'd be nice if you could do:

ctVal := header.HeaderW().LedgerSeqW().ValueW().ScpValueW().CloseTimeW().ValueW()
if ctVal.hasError {
  // ... has the first error that occurred during unwrapping
}

where the *W() variant returns a "wrapped" version that tracks whether or not there's an error, e.g.

struct LedgerHeaderW {
  LedgerHeader
  hasError error
}

func (*hdr LedgerHeaderHistoryEntryView) HeaderW() LedgerHeaderW {
	inner, err := header.Header()
	return LedgerHeaderW{LedgerHeader: inner, hasError: err}
}

// and so on

where each child method just propagates the error until the end if it's present. I could be making up Go semantics here and maybe this isn't possible, but it'd be a way nicer api ux if we could chain it this way. @tamirms is this even tenable in Go or am I making up syntax?

It seems possible but that wrapped types would have to go into the go-stellar-sdk and can't be done here.

I'm not sure that's worth it at this time just to make the error handling a little nicer

Oh yeah 100% this is just a side comment from the actual PR here

Turns out the SDK already generates this: Must* accessors panic with *ViewError and xdr.Try recovers them. da9ee15 switches to that style and deletes the local helper.

Bruh I keep forgetting that that exists

Maybe I'm misunderstanding here: this order from current RPC operates on a per-ledger basis. Are you suggesting that this creates a list of orders that are then correctly interleaved later?

It doesn't interleave later. I forgot about the event ordering

Edit: It passes off the interleaving to the ingest system downstream. This is just the extraction of all events with the correct IDs to be used to order later

It follows the same part of getting the payload out as the code you linked where ops happen after all tx events.

And to get the correctly ordered events you'd just iterate through the event indexes

should-fix: The decode can be removed entirely. The transaction hash can be computed directly from the wire bytes as SHA256(networkID ‖ envType-tag ‖ innerTx.Raw()). If the network ID is computed once per call and the SHA256 state is reused, hashing allocates nothing per envelope. The TX_V0 case hashes as its V1 conversion, which on the wire only adds the 4-byte muxed key-type prefix before the source key; the V0 optional-TimeBounds encoding and the V1 Preconditions encoding are identical, as are all the fields after them. The isSoroban flag can be read from V1().Tx().Ext(), or the fee-bump inner equivalent. Regarding aad6776: once the envelope type and the soroban flag are derived from the view, nothing needs the decode anymore. Separately, it would be worth adding TX_V0-envelope fixtures — no current fixture exercises one.

Done in da9ee15. envPartFromView no longer decodes the envelope: the hash is computed straight from the wire as SHA256(networkID ‖ envType tag ‖ innerTx.Raw()), with the network ID derived once per extraction and a reused SHA-256 state, so per-envelope hashing allocates nothing. TX_V0 hashes as its V1 conversion (4-byte ed25519 key-type prefix + the unchanged V0 bytes — the optional-TimeBounds/Preconditions equivalence is documented on the function), and isSoroban now reads the inner Tx.Ext view discriminant. Added TX_V0 fixtures with TimeBounds present and absent, paired against the reference path.

should-fix: This switches on the same discriminant twice: dispatchLCM calls openHeaderAndTxProc and then re-opens lcm.V0()/V1()/V2() to get the TxSet. The comment saying the TxSet open "cannot share this path" doesn't quite hold, because the enumerateEnvs closure already absorbs the type differences. Could this be a single dispatch that returns the header, the TxProcessing iterable, and the envelope enumerator, with the events path simply ignoring the enumerator?

Done — dispatchLCM (now in dispatch.go) is the single switch, returning the header, the TxProcessing sequence, and a lazily-opened envelope enumerator. openHeaderAndTxProc is gone; ExtractEvents and ExtractTxHashes use the same dispatch and just never touch the enumerator.

suggestion: This hashes every TxSet envelope even when limit is 1. Since the page's hashes are collected before the envelopes are enumerated, the enumeration could stop as soon as every page hash has been resolved. For small pages that is most of the cost of the call.

Done — ExtractTransactions collects the page's hashes first and envelopesForHashes stops the TxSet enumeration as soon as every wanted hash resolves.

should-fix: Two things here. First, the doc block attached to viewChain opens with readLedgerHeader's documentation, so the wrong declaration is documented and readLedgerHeader has none. Second, the comment says a fluent API "would need SDK-generated wrapper types", but the Go SDK already generates them: the Must* accessors chain fluently and Try recovers their failures as errors. With that style this helper disappears entirely.

Done — viewChain/step are deleted; readLedgerHeader and readTxHash use the generated Must* chains under xdr.Try, and the doc comment is back on the right declaration.

question: ExtractEvents emits V3 events whenever SorobanMeta is present, relying on the core invariant, while the read path additionally gates them on the envelope (gateV3ContractEvents). On an inconsistent LCM, the events index and getTransaction would therefore disagree about the same transaction. That is fine under the trusted-input assumption, but since this is a package-level contract, would you move the invariant statement into doc.go so that both halves reference one place?

Moved into doc.go as the package's trusted-input invariant; payloadsFromV3SorobanMeta and gateV3ContractEvents both reference it now.

nit: Both sides are [32]byte, so h == xdr.Hash(hash) works instead of bytes.Equal.

Done.

nit: This check can't fire: HashView is a fixed opaque[32], so Value() always returns exactly 32 bytes on success.

Removed — readTxHash converts with xdr.Hash(hb) directly.

nit: gofmt has reflowed the V0/V3/V4 list in this doc comment into stray indented blocks, which will render as code in godoc. It needs reformatting as a proper list.

Reformatted as a proper bullet list.

nit: A content match would also pass for a copy that happens to match at a unique offset. events_test.go proves aliasing correctly with unsafe.SliceData pointer containment; could we reuse that helper here?

Done — assertAliasesRaw now proves aliasing by unsafe.SliceData pointer containment; the content scanner is gone.

nit: Several comments narrate review and benchmarking history: "wished for in review", "previously-0%-coverage", "FAILS on the old positional code", and the rpc-hack provenance notes. The PR description already preserves that history. Could the code comments keep just the forward-looking contracts?

Swept — all of them are gone (the "wished for in review" one went with viewChain itself).