@rymnc let me know if this will work on the core side.

Regarding the fields total_cost and total_size, I assume this wasn't a hard requirement. It would require some additional effort on our side to be able to reconstruct these fields in case we loose the db and guarantee they are always accurate. From what I've got, they don't directly play into the pricing algorithm so I omitted them for now.

Instead of requesting the n last bundles I've went with a different approach where you tell us up until which height you have data and the committer respond with whatever came after.

@rymnc let me know if this will work on the core side.

Regarding the fields total_cost and total_size, I assume this wasn't a hard requirement. It would require some additional effort on our side to be able to reconstruct these fields in case we loose the db and guarantee they are always accurate. From what I've got, they don't directly play into the pricing algorithm so I omitted them for now.

Instead of requesting the n last bundles I've went with a different approach where you tell us up until which height you have data and the committer respond with whatever came after.

hmm, we could track total_cost and total_size on our own, but we would hope that the block committer keeps track of this information because we use it as a data source for new fuel-core nodes, especially the ones that need this pricing information.

cc'ing: @MitchTurner @xgreenx

Instead of requesting the n last bundles I've went with a different approach where you tell us up until which height you have data and the committer respond with whatever came after.

@MujkicA
This seems fine to me. Since when we rehydrate the algorithm from an old state, we are going to have to request "old" da costs that we have possibly received before.

On a connected note, it sounds like you aren't making any guarantees to the decompression guys about the order in which the blocks are recorded. I'm not sure what our conversation was before, but I think it might (with some small modifications) be fine for us to receive things out of order... however, that complicates what we query for.
i.e. if we are up-to-date up to block 30. We can tell you 30 and you might return a bundle of [32, 33, 36, 37] or something. We could record that, but we will still be saying 30 after because we need 31 still, which means you might send us two bundles next [31, 34, 35] and [32, 33, 36, 37]. Which seems like a little bit of a waste, but maybe we don't care!

@MitchTurner
Currently, the only way that fragments can happen to be posted out of order is if the L2 block lookback window was increased (e.g. because of misconfiguration) such that blocks that were ignored earlier are now targets for posting.
There are also some optimisations that we plan to tackle in the near future that could lead to out of order fragments if an L1 re-org occurs.

Note that both of these scenarios are edge-cases and since bundles usually consist of multiple fragments they're even less likely to be finalised out of order. The api will only report the cost for a block range if the corresponding bundle was marked as finalized (meaning all transactions carrying it's fragments have settled). I guess this doesn't absolve you from having to implement support for it but i maybe the details have some relevance to you.

Alternatively, we could only report back costs up until we have a contiguous range. This would cause a delay in reporting more recent costs in those edge cases so it's up to you.

At any rate, I'll deploy whatever version you prefer to the test networks so that we can test the integration.

Alternatively, we could only report back costs up until we have a contiguous range. This would cause a delay in reporting more recent costs in those edge cases so it's up to you.

I'd rather receive them ASAP than in order.

Clippy seems to be complaining about something 👀