removed constant repeating of "waiting" info log lines. Only first log is info level, the rest are debug.
Why are these changes needed?
Playing around with op devnet and eigenda-proxy. Logs are super cluttered and not hard to find the useful content in them. It's just pages and pages of this:
Related questions
1. finality vs confirmationDepth
I've also noticed that the eigenda_client has a single binary WaitForFinalization flag, instead of a more granular confirmationDepth flag like in eigenda-proxy. Is this on purpose? Or should eigenda-client also adopt a more granular notion of "finality", such that some clients might be happy with 10 blocks of confirmation, without necessarily wanting to wait for 2 epochs worth of confirmations (finality)?
2. BlobStatusReply including timeToDispersal ?
It might be nice as an additional feature to add to the BlobStatusReply returned by eigenda when requesting the status of a blob (used to wait for dispersal) a field timeToDispersal or something like this, as an estimate of the time left before the next batch dispersal. eigenda-client could then use this information to print in the log line the estimated wait time until the blob gets dispersed.
Checks
[ ] I've made sure the lint is passing in this PR.
[ ] I've made sure the tests are passing. Note that there might be a few flaky tests, in that case, please comment that they are not relevant.
[ ] I've checked the new test coverage and the coverage percentage didn't drop.
removed constant repeating of "waiting" info log lines. Only first log is info level, the rest are debug.
Why are these changes needed?
Playing around with op devnet and eigenda-proxy. Logs are super cluttered and not hard to find the useful content in them. It's just pages and pages of this:
Related questions
1. finality vs confirmationDepth
I've also noticed that the eigenda_client has a single binary WaitForFinalization flag, instead of a more granular confirmationDepth flag like in eigenda-proxy. Is this on purpose? Or should eigenda-client also adopt a more granular notion of "finality", such that some clients might be happy with 10 blocks of confirmation, without necessarily wanting to wait for 2 epochs worth of confirmations (finality)?
2. BlobStatusReply including timeToDispersal ?
It might be nice as an additional feature to add to the BlobStatusReply returned by eigenda when requesting the status of a blob (used to wait for dispersal) a field
timeToDispersalor something like this, as an estimate of the time left before the next batch dispersal. eigenda-client could then use this information to print in the log line the estimated wait time until the blob gets dispersed.Checks