Update:

After trying and testing different approaches, feel that the approach where I add an event listener and corresponding functions to handle the Auth Failure event in ConnectionBootstrap.tsx is a viable approach.

I made code changes as shown below, and tested as discussed with @mattrunyon by clicking "Work Offline" to go offline -> Restarting the Deephaven server -> clicking "Work Offline" again to go online. This is seeming to work, but there are a couple of issues:

a. Adding the logic here would make most of the logic from lines 725 - 763 of AppMainContainer.tsx in the code-studio redundant, specifically the listening for the disconnect and the auth failed. However, we would still need something for handling reconnect there. Or, we could move all of it to the connection bootstrap, but I am hesistent about doing so until I know the reason why the ConnectionBootstrap.tsx only handled disconnect (not reconnect and auth failed) prior to my changes, since that was not one of the changes implemented in #1149

b. The modal that appears in the embed-widget is similar to the one that we see in the main code-studio, but there are styling differences, not sure why?

c. The refresh here works but then the variable does not persist, I know that there are workarounds with this with Application Mode and initializing server state, but I feel like a solution should not be contingent upon using a specific mode.

@mofojed @mattrunyon any thoughts?

Some of the code changes:

Difference in Modal Styling:

In Code Studio:

In Embedded Widget Screen:

@AkshatJawne
a) ConnectionBootstrap was created after the JS API Reconnect PR (#1180 was after #1149). Possible the ConnectionBootstrap PR was started in parallel and didn't add all the reconnect logic there, so I think reasonable to include that reconnect login in ConnectionBootstrap
b) It looks like some fonts may not be loading? I'd double check that the fonts are loading correctly in embed-widget.
c) The variable will not persist if you restart the Deephaven server; there isn't anything we can do about that, since it's a new server instance. Are you restarting the Deephaven server as part of the steps to reproduce? If not, then the variable should still exist, and we shouldn't be getting a variable not found error, something else must be going on.

a) ConnectionBootstrap was created after the JS API Reconnect PR (#1180 was after #1149). Possible the ConnectionBootstrap PR was started in parallel and didn't add all the reconnect logic there, so I think reasonable to include that reconnect login in ConnectionBootstrap

This makes sense, I just wanted to make sure that my changes were not taking the wrong side of a design tradeoff that may have been made when creating the ConnectionBootstrap

b) It looks like some fonts may not be loading? I'd double check that the fonts are loading correctly in embed-widget.

Yes, it appears so, will take a deeper dive here

Are you restarting the Deephaven server as part of the steps to reproduce? If not, then the variable should still exist, and we shouldn't be getting a variable not found error, something else must be going on.

Yes I am, that was the way that @mattrunyon and I could reproduce the issue. But yeah, the creation of the new server instance having that behaviour makes sense, and if it is unavoidable, then no issues on that front.

Will continue working on this and will update on progress, thanks for the comment @mofojed

You could restart the server and then recreate the variable in a separate browser. Or run the server using app mode to create it at startup.

Unless there's another easy way to simulate the auth reconnect failure. @mofojed