add index to GSFA response

[0xMavi]

Summary

• Adds a transactionIndex field to getTransaction and getSignaturesForAddress RPC responses
• The index represents the transaction's 0-based position within the block's flattened transaction list
• Enables clients to determine transaction ordering within a block without fetching the entire block

Changes

• Added index: u32 field to ConfirmedTransactionWithStatusMeta and ConfirmedTransactionStatusWithSignature structs
• Modified find_transaction_in_slot in blockstore to return (VersionedTransaction, u32) tuple
• Updated find_address_signatures_for_slot to return index alongside slot and signature
• Added transaction_index to RpcConfirmedTransactionStatusWithSignature and EncodedConfirmedTransactionWithStatusMeta response types
• Updated BigTable storage layer to propagate index through transaction lookups
• Updated CLI code to ignore new struct field

Testing

• Updated existing unit tests in blockstore.rs to verify index values are correctly returned
• Tests confirm index matches expected transaction position within entries

[sam0x17]

few nits, looks good, going to run CI

[sam0x17]

now that I'm seeing this, would be much more efficient if we could avoid doing an iter-level clone here, much better not to clone/copy until we find the versioned transaction we are looking for. Would you mind tweaking that?

[0xMavi]

Good catch! Switched to .into_iter() which consumes the owned Vec - so we don't need to clone the found transaction in the end.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 95.45455% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.7%. Comparing base (dca7a1f) to head (dfdb510).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff            @@
##           master    #9683    +/-   ##
========================================
  Coverage    82.7%    82.7%            
========================================
  Files         853      853            
  Lines      319382   319467    +85     
========================================
+ Hits       264145   264269   +124     
+ Misses      55237    55198    -39     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sam0x17]

Just needs that one change and to pass code coverage looks like

[sam0x17]

An additional problem I missed:

the addition of transaction_index to RpcConfirmedTransactionStatusWithSignature and EncodedConfirmedTransactionWithStatusMeta would be a breaking change. We should make this Optional + Default so older clients/nodes don't break things when they don't support the field. Should probably do something like:

#[serde(default, skip_serializing_if = "Option::is_none")]
pub transaction_index: Option<u32>;

[sam0x17]

make non-breaking change by using optional fields

[sam0x17]

Looks good!

[sam0x17]

semver issue

So right now this PR still adds index: u32 to internal/public structs like:

• ConfirmedTransactionWithStatusMeta { …, index: u32 }
• ConfirmedTransactionStatusWithSignature { …, index: u32 }

That’s an additive field, but in Rust it’s still breaking for downstream users doing struct literals or exhaustive destructuring, so this would break semver. In the very least, we need a change that makes these fields optional + default None.

I am double checking with the team to see if this should be a minor bump or a major bump, but minimally we should make it Option

slot vs transaction_slot nit

In find_address_signatures_for_slot, it currently pushes (slot, signature, transaction_index) using the function parameter slot rather than the transaction_slot read from the iterator. It’s probably fine because of the loop’s break condition, but it would be good to tweak this for clarity and future-proofing.

[sam0x17]

Ok I got some clarity, this would indeed be a major version bump because of the addition of fields on public structs

But that is fine, because master is already on 4.0

[sam0x17]

Ok this looks good now, I misspoke about the two last struct changes, we should be good to merge this in 4.x as soon as CI passes