rebase

rebase

thx for fixing this

format

It's all done in D4425 this can be abandoned

rebase

rebase

address feedback

https://linear.app/comm/issue/ENG-1366/figure-out-modifying-variables-inside-of-the-rusts-generator

rebase

rebase

address feedback

rename

change err msg

address feedback

rebase

rebase

don't return anything

thx

My high-level perspective is that you are the only person on the team who ever has diff stacks this large.

Yes, everything you see in the docker desktop is a visual indication but it shows what really goes on underneath, doesn't it?

Here are 2 images - one with and one without the label:

In D4375#126918, @ashoat wrote:

What do you mean by "label"?

This diff is now blocking 31 following accepted diffs. So if this gets accepted, we're able to land 32 diffs. Otherwise, we're going to stay with this huge stack dangling and every day there may be more and more commits on master making it harder to rebase and land later.

revert redundant change

@geekbrother can you show your "images" tab as well?

Separately - we checked on Jacek's m1 machine and he also had that "amd" label on the blob service. I also have this label for the tunnel broker and it was building really slow. Wondering how @geekbrother managed to run the tunnel broker without this.

address offline feedback

Maybe @jimpo or @jonringer-comm could help?

I assume you tested this code before without Arc? Do you know when exactly this is being reused, in other words, when exactly this Arc comes into play? And what would cause this code to fail if we don't use Arc?

I'm unfortunately still confused here. I read through @karol-bisztyga's comment twice, but I still don't understand what this is solving and why it's necessary.

It's my perception that you are putting yourself in this position – every time you want to make a change, you make a new diff.

In D4439#126271, @ashoat wrote:

I'm concerned that we're simply trusting the client to truthfully state this info. @karol-bisztyga, can you come up with a way we can move forward here without relying on the client to communicate this info to the blob service?

In D4375#126323, @ashoat wrote:

(Just a reminder, this diff is blocked on this investigation)

Also - look at your comment here: https://phab.comm.dev/D4439#126271

Responded in the linked diff. I think doing a follow-up is far less expensive for both sides and works a lot better.

rebase

address fdbck

We've been in this situation multiple times. Look at the size of this stack. Do you realize how expensive is to keep amending and rebasing? It also makes it harder for the reviewers because if I amend an existing commit I should re-request a review even on the accepted diffs. So I don't do this because I'm selfish-lazy and just want to make everything comfortable for myself. That results is you reviewing the same code again and again only because I had to change one line or something. I don't know how this even works for you but for me, it is just a mess. Please look at this stack. It's almost all green and you keep blocking the very first diff of this stack. Why cannot we just land this and address the changes later instead of amending these diffs forever?

Where did these values come from?

See, I'm getting something like this (when not building with the .m1 suffix)

revert invalid change that was caused by the crash if vi

err msg

err msg

err msg

add sanity check

add sanity check

change ternary

@yayabosh when can I expect a review from you here? You are a blocking reviewer... thx

address fdbck

Here is a follow-up with the solution split into 4 diffs

CI is broken

CI is broken