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

[Access] Improve SendAndSubscribe status handling #6574

Open
Tracked by #6163
peterargue opened this issue Oct 18, 2024 · 0 comments · May be fixed by #6736
Open
Tracked by #6163

[Access] Improve SendAndSubscribe status handling #6574

peterargue opened this issue Oct 18, 2024 · 0 comments · May be fixed by #6736

Comments

@peterargue
Copy link
Contributor

Problem Definition

Currently, the SendAndSubscribeTransactionStatuses endpoint will first return a message that the tx is pending, then finalized, executed and sealed all at once.

2024-10-16 07:19:48.442 INF transaction PENDING successfully
2024-10-16 07:19:51.646 INF transaction FINALIZED successfully
2024-10-16 07:19:51.646 INF transaction EXECUTED successfully
2024-10-16 07:19:51.647 INF transaction SEALED successfully

sometimes, finalized is returned earlier, but executed and sealed are returned at once.

2024-10-16 07:21:09.504 INF transaction PENDING successfully
2024-10-16 07:21:13.288 INF transaction FINALIZED successfully
2024-10-16 07:21:16.251 INF transaction EXECUTED successfully
2024-10-16 07:21:16.251 INF transaction SEALED successfully

The goal of this endpoint is to provide feedback to the user quickly as the changes are happening, so waiting until the block seals to return the TransactionResult breaks that.

I'm not totally sure why, but I bet it's related to this check

_, err := b.executionResults.ByBlockID(txInfo.BlockID)
if err != nil {
if errors.Is(err, storage.ErrNotFound) {
return nil, nil
}
return nil, fmt.Errorf("failed to get execution result for block %s: %w", txInfo.BlockID, err)
}

That doesn't explain why it sometimes returns finalized at the same time as executed and sealed. it's possible that's because the node took a long time to get the collection from the collection nodes, but we should review the code closely to identify if there are any other sources of delays.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants