Skip to content
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

Fix diagnostic event parsing bug #199

Merged
merged 1 commit into from
Oct 3, 2023
Merged

Conversation

chowbao
Copy link
Contributor

@chowbao chowbao commented Oct 3, 2023

Fixed diagnostic event parsing to account for events without a contract_id

@chowbao chowbao requested a review from a team as a code owner October 3, 2023 18:33
Copy link
Contributor

@sydneynotthecity sydneynotthecity left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@@ -51,6 +51,12 @@ func TransformDiagnosticEvent(transaction ingest.LedgerTransaction, lhe xdr.Ledg
continue
}

if event.ContractId != nil {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Curious, in what scenarios would the ContractId be null? Would this be null during the original WASM upload to host?

Copy link
Contributor Author

@chowbao chowbao Oct 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes that's one case but I also think it's unoptimized diagnostic events.

Example transaction_hash: 559f7422e90d054d77cbc32a756af55ff9838ca077f75b2e8b8329971b9eb57c
The transaction failed because invokeHostFunctionResourceLimitExceeded but it doesn't give you the contract_id that was used because the resource error is associated with the transaction and not necessarily a problem with the contract being invoked.

Could it have given a contract_id? Yes but it doesn't 🤷‍♀️
Can we find out the contract_id? Probably yes, with joins to transaction_id --> history_operations --> contract_id

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, that makes sense. I don't think we need to always find the contract_id, we can leave that up to the user if they need to trace

@chowbao chowbao merged commit 1132c44 into master Oct 3, 2023
2 checks passed
@sydneynotthecity sydneynotthecity deleted the fix-diagnostic-event-bug branch December 19, 2023 16:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants