[Access] Add implementation BlockProvider #6636
Conversation
… and block provider
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #6636 +/- ##
==========================================
- Coverage 41.26% 41.19% -0.07%
==========================================
Files 2061 2066 +5
Lines 182702 182920 +218
==========================================
- Hits 75384 75350 -34
- Misses 101010 101262 +252
Partials 6308 6308
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
engine/access/rest/websockets/data_providers/blocks_provider.go
Outdated
Show resolved
Hide resolved
…d ctx from HandleSubscription
engine/access/rest/websockets/data_providers/blocks_provider.go
Outdated
Show resolved
Hide resolved
engine/access/rest/websockets/data_providers/blocks_provider.go
Outdated
Show resolved
Hide resolved
engine/access/rest/websockets/data_providers/blocks_provider.go
Outdated
Show resolved
Hide resolved
|
Please, wrap LGTM |
…:The-K-R-O-K/flow-go into UlyanaAndrukhiv/6585-block-data-provider
| // Run starts processing the subscription and handles responses. | ||
| // | ||
| // No errors are expected during normal operations. | ||
| Run() error |
There was a problem hiding this comment.
@peterargue, the idea behind separating the creation of the data provider and the Run() method is to provide better control over the subscription lifecycle. By doing this, we can immediately send a message to the client confirming that the subscription has been successfully created or failed. The actual subscription and data streaming process will only start after calling Run(), which ensures that we can handle any setup or preparation steps first. Since Run() starts processing the subscription, we do not need the ctx at this point.
There was a problem hiding this comment.
can you add a comment with this context in BaseDataProvider or wherever you think makes it most clear. I think future readers will wonder this as well.
engine/access/rest/websockets/data_providers/blocks_provider.go
Outdated
Show resolved
Hide resolved
…:The-K-R-O-K/flow-go into UlyanaAndrukhiv/6585-block-data-provider
There was a problem hiding this comment.
mostly smaller comments. I think you should expand on the data provider tests to include some happy path testing. I also think there's currently a gap that covers more end-to-end functional testing. That can come in a separate PR, but wondering if we will need more control than is possible using integration tests alone. what do you think?
| c.dataProviders.Add(dp.ID(), dp) | ||
| dp.Run(ctx) | ||
|
|
||
| //TODO: return OK response to client | ||
| c.communicationChannel <- msg |
There was a problem hiding this comment.
this is returning the request back to the client?
There was a problem hiding this comment.
this is fixed here https://github.com/onflow/flow-go/pull/6762/files#diff-3dc4a79384159575e2c161dbc797a45dea7b38850629edef25b4a9a1cbc2533aR200
We have a bunch of places where we return sth we should not. I'll fix all of them in #6642
engine/access/rest/websockets/data_providers/block_headers_provider.go
Outdated
Show resolved
Hide resolved
| // Run starts processing the subscription and handles responses. | ||
| // | ||
| // No errors are expected during normal operations. | ||
| Run() error |
There was a problem hiding this comment.
can you add a comment with this context in BaseDataProvider or wherever you think makes it most clear. I think future readers will wonder this as well.
| finalizedBlock *flow.Header | ||
| } | ||
|
|
||
| func TestBlocksProviderSuite(t *testing.T) { |
There was a problem hiding this comment.
can you also include happy path tests?
Closes: #6584 , #6585
Context
In this PR implemented :
DataProviderFactorywhich is responsible for creating data providers based on the requested topic.DataProviderwhich is the interface abstracts of the actual data provider used by theWebSocketCollector.BaseDataProviderandBaseDataProviderImpl- the interface and the concrete implementation which holds common objects for the provider.BlocksDataProviderwhich is responsible for providing blocks.BlockHeadersDataProviderwhich is responsible for providing block headers.BlockDigestsDataProviderwhich is responsible for providing block digests.Added unit tests to cover this functionality.