I think we might want to add this check back or something similar to it. It is poorly named but basically it was making sure we only display an API error on the first workspace rather than duplicating it on each workspace (it was pretty noisy, especially since the API errors can get long).

For example, say you have 5 workspaces and your token expires, you see a message about being unauthorized and to check your token 5 times on the page.

Or we could group workspaces under a deployment heading and show the API error under the deployment heading, but that might be out of scope for this PR.

It looks like atm the moment I actually have this inside the connections.foEach loop (which makes me think with multiple WorkpaceProjectIDE combos it would render multiple times). I didn't notice because I was visually testing with one recent connection.
I'll pull it out of the loop and add the check.

^^^ My adhd is going to quickly become a driving force for building out E2E suites.

Not at all a blocker and completely optional, more just idly musing, but I wonder if we want to turn the pair back into a triple and put a nullable icon in there, which would let us also show a spinner while the query is running as well (like it used to) and bring back the error icon for API errors (if we want, honestly the red color is probably sufficient).

I think adding the error icon back is a good idea and fits in this PR :)

I opened#465 for future improvement

idk if this is more Kotlin-y but I think you can also do something like this over the assertion:

status.third?.let { icon (it) }

Admittedly untested though

I low key hate that they named a functionlet 💀 TBH I think the assertion here is clearer, but if that's the kotlin way then I'm game haha. I could also do awithoutNull I suppose.

withoutNull throws if null but here we are OK with the status potentially being null, so I think it would not quite fit here.

I think the main issue with assertions is that they bypass the safety provided to you by the language, which feels dangerous for an unclear benefit.

If you see a!! you need to reason about the entire code and determine thatstatus.third is not going to be reassigned (and you need to do this every time related code is refactored), but we should let the machine do it for us. 😆 Admittedly it is pretty trivial in this case, but still!

Yeah I meant use withoutNull inside the if check, but you're totally right thelet method is the best option here, I just wish they called it somewhere else lol.

ahaha yeah and I swear I have to look it up every time because I always forget it is calledlet