Context as a Field in HeaderSyncService and BlockSyncService

[oxnr]

Finding 003 - Context as a Field in HeaderSyncService and BlockSyncService

ID	003
Finding	Context as a Field in HeaderSyncService and BlockSyncService
Severity	2 - Informational
Description	Both the HeaderSyncService and BlockSyncService types have a Context field as part of the type. Many methods on these types accept a Context argument from the caller, which is ideal. Not only does this make the internal Context field unnecessary, it’s also an indication of a codesmell and should be removed.
Recommendation	As most of the methods already accept Context as an argument, remove the Context field from both HeaderSyncService and BlockSyncService. For methods that do not accept a Context, update them to accept a Context from the caller in order to manage lifecycle events properly, e.g. Start.
Code References	https://github.com/rollkit/rollkit/blob/eccdd0f1793a5ac532011ef4d896de9e0d8bcb9d/block/header_sync.go#L44https://github.com/rollkit/rollkit/blob/eccdd0f1793a5ac532011ef4d896de9e0d8bcb9d/block/block_sync.go#L43

[Manav-Aggarwal]

Need to make the change in https://github.com/celestiaorg/go-header/ since HeaderSyncService and BlockSyncService implement the go-header interface.

[AryanGodara]

@Manav-Aggarwal Is this an issue that we can propose to the go-header project? It'll be an interesting issue to tackle across repositories

[Wondertan]

HeaderSyncService and BlockSyncService implement the go-header interface.

These services do not implement any of the interfaces defined in go-header. Furthermore, interfaces can't enforce storing a ctx field on the struct, so I don't think this is related to go-header anyhow.