split_barrier may require some unit tests to be restored
Agree, this should be covered. However, the new implementation is quite a lot simpler and easier to reason about than the old one so perhaps tests are not as high priority?
Also, currently an unbounded vec is being used.
Prefer to have a further check on this.
I don't think this is a problem. Worst case is probably multiple fork during split. So let's say we accumulate N entries for the 0-ending subsection. Then once we get the first entry for the 1-ending subsection, all those entries are going to be removed and applied to the Section / Network structs. Then any subsequent 1-ending entries aren't even going to the split barrier because the split has already been finalized. Don't think there is a possibility for unbounded growth.
Agree, this should be covered. However, the new implementation is quite a lot simpler and easier to reason about than the old one so perhaps tests are not as high priority?
I don't think this is a problem. Worst case is probably multiple fork during split. So let's say we accumulate
Nentries for the0-ending subsection. Then once we get the first entry for the1-ending subsection, all those entries are going to be removed and applied to theSection/Networkstructs. Then any subsequent1-ending entries aren't even going to the split barrier because the split has already been finalized. Don't think there is a possibility for unbounded growth.