das: DASer should kick off without waiting for new header event

[Wondertan]

The DASer does not kick off instantly and waits until at least one recent header is received from the network. Instead, DASer should kick off instantly on the node start by detecting that the current stored Head is higher than the last sampled height.

[Wondertan]

It seems like this can only happen in case the node is started from complete zero, i.e, store.Head.Height == 1, and in that case it will wait until new header arrives

[renaynay]

AFAIU the only case where this is an issue is in testing where pubsub is unreliable.

[Wondertan]

And only in case the node is started afresh, according to the code.

[Wondertan]

Currently, DASer checks the store's head as a network head only when it constructs checkpoint during start time, so the option is either we make Daser check for the store's head somewhere in runtime like next to the newJob or we do nothing and live with this issue(which is not that bad)

[walldiss]

i agree that it could be only an issue if it is fresh star of the node and with unreliable pubsub. Which is very rare case.
If we want to target this issue, I think it would be easier to modify logic in subscriber component in DASer. There are two ways we can do it:

• add occasional checks to store on DASer side
• modify header sub. DASer subscriber component follows the NextHeader value from headerSub, that follows network head. DASer could follow interface, that follows store head.

[Wondertan]

We could introduce an event system for the latest heads stored in the store(a more generalized second issue). I think we will come to it at some point, but until then, we may go with the first option. I would propose in the coordinator loop to check the store if no new jobs were received for some time.

[walldiss]

Coordinator loop is blocked if there are no events of discovered network head. I would rather extend subscriber component. It could be done by launching extra store checking routine (aka store discovery), that would run until headersub (aka network discovery) yield first header.

I would rather not touch logic of coordinator to keep it simple and avoid it becoming too dependant on components.

[renaynay]

I think DASer not receiving headers through header subscriber is symptomatic of a larger problem and I'm not really sure if putting a bandaid on that by introducing fallback to store is a good idea. Initially, @walldiss really did want to treat the header package kind of as a blackbox which I appreciate, and technically it should be guaranteed that the DASer kicks off within max blocktime (which is 15 seconds) as in a healthy network, a header is received ever 15 seconds.

[Wondertan]

@walldiss, your idea sounds good to me. Let's move the proposed Head check from the coordinator to a place where it's more appropriate, while keeping coordinator simpler

[renaynay]

I still do not understand why this is an important fallback to prioritise - this is only observable if header-sub fails, which should not happen and is symptomatic of a deeper network issue.

[Wondertan]

No priority is put into it; just an issue with a discussion. I also made it in the begging with the wrong assumption that it happens more often. Note that it also happens when you start the node for the first time, and users may have to wait up to 15 secs until the DASer kicks in, so it's also UX issue