[Access] Make WebSocket responses from data providers consistent with Access REST API responses #6802
Conversation
…The-K-R-O-K/flow-go into UlyanaAndrukhiv/6775-websocket-responses
…-events-data-provider
…The-K-R-O-K/flow-go into UlyanaAndrukhiv/6775-websocket-responses
…The-K-R-O-K/flow-go into UlyanaAndrukhiv/6775-websocket-responses
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #6802 +/- ##
========================================
Coverage 41.18% 41.18%
========================================
Files 2109 2116 +7
Lines 185660 185866 +206
========================================
+ Hits 76460 76549 +89
- Misses 102788 102902 +114
- Partials 6412 6415 +3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
…:The-K-R-O-K/flow-go into UlyanaAndrukhiv/6775-websocket-responses
| // If the execution result is not yet available, it returns a nil execution result and no error. | ||
| // | ||
| // No errors are expected during normal operations. | ||
| func (p *BlocksDataProvider) getExecutionResult(b *flow.Block) (*flow.ExecutionResult, error) { |
There was a problem hiding this comment.
We cannot use ExecutionResults from the block payload because they are not the execution results for this block. In the REST block response, the execution result specific to the block is expected. Therefore, I retrieve it from storage using the block ID.
…ed response for SendTransactionStatusesDataProvider, updated test
…:The-K-R-O-K/flow-go into UlyanaAndrukhiv/6775-websocket-responses
| subscription.HandleResponse(p.send, func(b *flow.Block) (interface{}, error) { | ||
| var block commonmodels.Block | ||
|
|
||
| executionResult, err := p.getExecutionResult(b) |
There was a problem hiding this comment.
can you remind me why this is needed? I would expect the flow.Block object to already contain the correct execution results.
There was a problem hiding this comment.
I had a discussion with Yurii @durkmurder about execution results in flow.Block and the execution results from the flow.Block Payload cannot be used because they are not the execution result for this specific block.
Since the REST API block response is expected the execution result specific to this block, I retrieve it from storage by block ID.
There was a problem hiding this comment.
Discussion result:
- Remove of
expandas an argument for Websocketsblocksubscription. - Do not include the
execution resultinto block response. - Always return the
payloadin block response.
…github.com:The-K-R-O-K/flow-go into UlyanaAndrukhiv/6775-websocket-responses
…github.com:The-K-R-O-K/flow-go into UlyanaAndrukhiv/6775-websocket-responses
…xecution result from response, added payload to result
Closes: #6775
Note: this PR should be merged after #6818
Context
This pull request updates the
WebSocketdata providers to utilize the same models and response converters used by theAccess REST API. By aligning the data processing logic, responses fromWebSocketandREST APIendpoints will now have consistent structure and content. Updated and added new unit tests to validate shared model usage.