bug: emitOnBegin not working as expected

[antoinedc]

Is there an existing issue for this?

• I have searched the existing issues

Package Version

2.0.6

Current Behavior

When emitOnBegins is false, the first block emitted is still very often the latest block of the chain, because the first poll will retrieve it and emit it (unless a new block is emitted between the start & the first poll, but it's very unlikely with low polling intervals).
So, yes, technically, the flag is respected because the block is not emitted right on start, but the fact that it's emitted 1s later seems to defeat the purpose of it.
I assumed this flag was used to avoid catching the latest block and start with new ones, but maybe I'm missing the purpose here. (If so, would love to know the reasoning behind this).
The reason is when working with forked chains. Those chains are interesting only because of your own transactions, but when you start it and listen with viem, the first block that comes in is not one you mined but the latest mainnet one, filled with all the txs, and it's not relevant at all.

Expected Behavior

Only blocks mined after watchBlock is started are emitted

Steps To Reproduce

• Start a forked chain (or a new one and let it mine a few blocks)
• Start watchBlocks with a low (1s) polling interval
• At the first polling interval, the emitted block will be one that has been mined before watchBlock was started

Link to Minimal Reproducible Example (StackBlitz, CodeSandbox, GitHub repo etc.)

No response

Anything else?

No response

[jxom]

The purpose of the emitOnBegin flag is to emit first, and then start polling, regardless of block number.

Maybe we can add a flag to start polling once a new incoming block comes in.

Moving this issue to a discussion labelled as "feature request".

[antoinedc]

I see, looks like I misunderstood the purpose of this flag then. It would be great to have this other flag, yes, though I have no idea how many developers would find it useful...