Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
congestion: glue together congestion info bootstrapping (#11361)
We still had an unresolved issue: Where in the code will the first congestion info be computed? This is referred to as bootstrapping the congestion info. In this PR, I suggest we let the runtime compute it inside `apply`, which means it is done on the shard level, rather than the chain level. I believe this makes sense, since we don't need anything other than the state trie to make this computation. And I'd rather not dig into the trie from the chain level. As a side-effect of this, the `ContextError` introduced for congestion control is no longer possible. Implementation errors, which would have previously caused this error followed by a crash, would now cause an expensive recomputation of the congestion info and print a warning. This PR also suggest a semantic change to how CongestionControl and CongestionInfo are used. I think we should clearly distinguish between: 1) Read-only usage of congestion info (through CongestionControl) when making congestion control decisions. 2) A congestion info we are still building. Thus, I changed the semantic of `CongestionControl` to only make sense for looking at previous chunks' congestion info. Consequently, ReceiptSink now only holds an instance of `CongestionInfo`. With this semantic change, the `CongestionControl` no longer has a need for add/remove function to modify internals. And the finalization of the allowed shard no longer makes sense on that struct, this should happen on the CongestionInfo only. But now we need a way to compute the congestion level on the `CongestionInfo` struct (without missed chunks) and one on `CongestionControl` (with missed chunks). At this point, the somewhat object-oriented approach to store the config inside `CongestionControl` no longer works as smoothly. Thus, a few more function need the config object injected at the parameter level. I have to admit, it's a bit more clutter. But I think it makes sense to use apply_state.config as source of truth rather than a copy of the config. I even tried to add another struct (e.g. CongestionInfoBuilder) to further make the distinction between mutable and read-only congestion info. But for my taste, it adds more clutter than justified. We already have too many different types. With all this justification for the semantic changes, I want to stress that I am still open to different semantics and code structures. Getting this right is important to me, to not make the runtime code a bigger mess than it has to be. This is just one proposal how it could be done.
- Loading branch information