If we are relying on chronik and ts here, we can assume blockTimestamp is defined every time in handleBlockInvalidated, since the function is only called on BLK_INVALIDATED msgs which include it

If we still want to handle it, then should use

const timestamp = typeof blockTimestamp !== 'undefined' ? blockTimestamp: 'unknown'

same comment as above

in this case, we are already assuming that coinbaseData is the expected shape. So we might as well assume it is also defined.

if we only ever call this on invalidated blocks, should never be undefined

good point, at this stage it's always defined indeed (while it's not in other handlers but we don't pass them down so it's a non issue)

This is true but I'd rather not rely on this, it is brittle as opposed to the invalidated callback which offers a strong guarantee

no need for this method

the getCoingeckoApiUrl function is a one-off thing ... exists because I over-engineered the coingecko methods in this app to support config-adjustable prices to display.

weird that this here is working

it's ok to just define this URL as a constant, e.g. in config.

lot of work to deal with this potential cache issue, which could also be a race condition depending on how fast blocks are coming in.

I can see how it could "work" and the info would be better than nothing.

We could modify chronik and chronik-client to fwd the getstakingreward RPC? Might be a useful template to support some other RPC calls going fwd.

Though practically speaking ... only makes sense if the chronik URL being used is an avalanche node, which is a whole nother thing.

we could just put the constant URL here, the use of getCoingeckoApiUrl(config) above is a weird case

Chronik is an indexer, its not it's role to provide a proxy for the node RPCs

Oups yes and the property should be cachedObject.address... leftover from a previous iteration, good catch

TIL