Anastasios Kichidis

+1 on this one, with the e2e tests we introduce recently (ex see [here](https://github.com/MystenLabs/narwhal/pull/560)) I see more and more the need for it. A point to add is that we...

> I think there are two topics: > > 1. conceptually, do we expose the internal batching structure when we retrieve a collection? That's certainly something we can revisit, but...

@jsteenb2 following our conversation summarising the observations we had so far: 1. Try to set the `batch_size` to a higher value than `5 bytes` (ex try with 50 or 100...

@arun-koshy @huitseeker this is what I am proposing for the `GetCollections` endpoint. I also took into account the complexity that the current compiler is introducing on the clients when nesting...

> Everything looks good to me the only thing I am curious about is your switch to separate fields instead of a nested repeated `oneof` > > > the complexity...

@arun-koshy thanks for the response. No problem from my side, I am not against the `oneof` but I thought it might be a bit simpler when accessing the collection it...

FYI the conversation we had when introduced this https://github.com/MystenLabs/narwhal/pull/393#discussion_r910103634 . So I don't know if that's a bug, but rather a decision made. I agree let's bring everything in same...

Following the discussions from this [lightweight design doc](https://www.notion.so/mystenlabs/Design-doc-match-received-batches-to-headers-e23703e2a4a342b1a3f54c4217276fc5) we'll go with solution 2, meaning keeping an LRU cache for each worker in primary that will act as a coordinator to...

@huitseeker if I understood the bug correctly, your are saying that we don't trigger the causal completion for the starting point of the DAG walk on the `read_causal` endpoint, right?...

Totally agree on this @bmwill . We do actually have an engineering goal on our road map around it ([see. 1.3 End-to-end testing](https://www.notion.so/mystenlabs/Demo-Stage-1-Better-Engineering-planning-9a94e0afe86246aa839999a7c2405a4d#89a4f361d4674cec8347592c15c95782)) so we are definitely planning to work...