Skip to content

Emit events as a top-level field in getTransaction response #389

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
leighmcculloch opened this issue Mar 27, 2025 · 4 comments
Open

Emit events as a top-level field in getTransaction response #389

leighmcculloch opened this issue Mar 27, 2025 · 4 comments

Comments

@leighmcculloch
Copy link
Member

leighmcculloch commented Mar 27, 2025

What problem does your feature solve?

When interacting with a transaction via simulateTransaction an array of base64 xdr encoded events is returned.

When interacting with a transaction via getTransaction no array of events are provided. The events are in the transaction meta though.

What would you like to see?

A top-level events field like what we see with the simulationTransaction method.

Events should be easily accessible and first-class field in the API.

What alternatives are there?

Do nothing and folks can get the events out of the transaction meta.

@2opremio
Copy link
Contributor

2opremio commented Apr 8, 2025

@leighmcculloch why not call getEvents directly instead? (I would rather not duplicate functionality)

@leighmcculloch
Copy link
Member Author

why not call getEvents directly instead?

getEvents doesn't take a transaction hash as a filter.

@leighmcculloch
Copy link
Member Author

Looking at this further, the simulateTransaction and getTransaction endpoints take such different shape.

getTransaction simulateTransaction
ledger
createdAt
applicationOrder
feeBump
envelopeXdr
resultMetaXdr
resultXdr results.xdr
stateChanges
events
minResourceFee
restorePreamble
results.auth
transactionData
error

Much of that makes sense.

The presence of events and stateChanges on simulateTransaction is nice though. I assume their presence is because we don't have a transaction meta value as a whole to return. The APIs and workflow for interacting with both are just so different. I think it's worth some effort of normalising the experience of getting events or getting state changes across the two.

@Shaptic
Copy link
Contributor

Shaptic commented Apr 15, 2025

I mean, those endpoints are completely different, so it makes sense for their shapes to have minimal overlap (result.xdr != resultXdr, btw); their functionality is disjoint.

The amount of work for the user to parse events out of the resultMetaXdr is basically identical relative to from a list of diagnosticEventsXdr (as in, they only have to add .v3().sorobanMeta.diagnosticEvents() (in JS) to their code); I don't see a meaningful value add duplicating the payload in a top-level field.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: To Do
Development

No branches or pull requests

3 participants