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 · 1 comment
Open
Tracked by #6163

[Access] Improve SendAndSubscribe status handling #6574

peterargue opened this issue Oct 18, 2024 · 1 comment
Assignees
Labels

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.

Copy link
Contributor

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the Stale Label used when marking an issue stale. label Feb 25, 2025
@franklywatson franklywatson added Preserve Stale Bot repellent and removed Stale Label used when marking an issue stale. labels Feb 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants