Just noting that this is in the future from the node's PoV. I think the impact of this is minimal, it maybe makes us attempt to respond to DataColumnsByRange requests from peers before the Fulu epoch is reached?

This doesn't seem to be a huge issue, as I think the block root iterator here will just be empty:

We have the same behaviour for blobs by range as well (when Deneb is scheduled but hasn't happened yet). I think this is OK, it's very cheap for us to respond to this request, so I think it doesn't pose a DoS risk

i think earliest_custodied_data_column_slot gives you the slot that columns advertised at the current cgc are all available right?

It may not necessary mean the node doesn't have a particular column. Would it be more suitable to use custdoy context to check for column availability here?

ah if we're ok with not serving columns while backfilling columns that's ok too - since peers are unlikely to request from us given our earliest_data_column_slot.

I was under the assumption that a peer will be requesting columns from us based on our nodes status v2 response. during a cgc change our status v2 will only return the earliest slot in which we've fulfilled our custody requirements for the current cgc. So they shouldn't request anything before the earliest_data_column_slot after a cgc change.

On a slightly separate note, if we didn't have custody backfill I could be convinced to cross reference custody context to figure out if we could actually serve a column or not. But because of custody backfill I think we should be ok with just checking the earliest_data_column_slot. It keeps things simple here with the caveat that we're not serving columns that we may potentially have for some limited period of time.