[jobelenus]

How does this PR change the system?

• Fixes a bug on main there is a bug where refreshing two tabs "at once". The first one gets stuck in the lobby. The tab that gets stuck has this in the console:

🌈 lock acquired by another tab (01KC9C7MN1TPEWHF3J6WAVSR21) 
🔥 MUSPELSTATUS:  {"01KC78YJYSF9713GP9PZGMT1M9":false,"01KBKC2H7WETEKGFD4YJMQ1XMA":false} 
🌈 lock acquired by this tab: 01KC9C7ZBDTRY9K7RPJX19EWH5

The leader consensus succeeds after the cold start was called. Which mean the cold start never runs at all. We just needed to wait inside heimdall.init so that we don't attempt a cold start before locks are acquired (and I lowered the timeouts in there). EDIT: We are still working this piece a bit, Zack is still getting hit with it. (It was on main prior to this PR, too)

• Once we are looking at a change set, set an interval to perform a cold start every 30 seconds. Whenever we receive an IndexUpdate (e.g. the client has definitively received new data) clear & restart the interval.
  • This will create unnecessary traffic for quiet workspaces, e.g. people just having a tab open. But... its hitting an endpoint backed by cache, so not terrible
  • 30 seconds before you get an update in the failure cases of patches not landing is not ideal—this is really just a backstop. I don't want to go any more frequently because it may get in the way of processing patches (when we cold start, we stop processing the queue of patches)
• Adding spans for when WS connections are open and closed.
• Bringing back the "WS disconnected" banner in the center nav, gated by an SI-cohort feature flag, so users aren't bothered by it yet.
• On cold start the cache of every item in the DB does not need to be busted.
  • In the "real cold start" case, no queries are run before you're out of the lobby, so there is nothing to re-query
  • In the "i switched changeset/periodic re-cold start", any data we dont have throws a hammer and that busts the query. I want to avoid large workspaces re-querying & re-rendering the list of components "randomly" when the periodic update fires, its a terrible experience we ran into once before.

Things that shouldn't happen under normal circumstances

• Tiny fix for completeness around ending a span in the case of an index no op patch, which shouldn't exist.
• Adding a client-side retry when an index is rebuilding and there is a potential the system does not send the index updated message and / or the client does not receive it (whether the system is being deployed, SDF instances are being cycled, messages are dropped, WS connection is lost). Were any of those things to happen a user would sit in a lobby until they refreshed the page.

Feature Flag:

show-ws-disconnect @ https://us.posthog.com/project/20369/feature_flags/287564

How was it tested?

Disconnect notification

1. load the app
2. disable SDF in tilt
3. see the "disconnected" banner
   Override the feature flag to false and repeat—do not see the banner

Webworker changes

First scenario

1. open two tabs
2. wait to see interval firing cold starts
3. continually create a components in one tab
4. do not see concurrent cold starts (e.g. 2 tabs fire 1 cold start)
5. Fixed: There was a bug in my implementation where tabs that didn't have the lock would only see the "lost connection" message.

Second scenario

1. Create a new change set
2. Copy the URL & close all your local web app tabs
3. Use CLI tool to update a component (e.g. name change) on the non-HEAD change set
4. Paste the URL into a new browser tab
5. See the cold start throw a hammer for the new component & the new component displayed in the UI

[github-actions]

Dependency Review

✅ No vulnerabilities or OpenSSF Scorecard issues found.

Scanned Files

None

[jobelenus]

@zacharyhamm brought up a good point. If a user has multiple tabs open on a workspace, we'll get multiple clients firing periodic updates to cold start

I wanted the call for periodic updates in the client because we know what change set the user is looking at.

We are going to add a call to the web worker interface for a per change set throttle to cold start. This way multiple clients could be polling, and we still don't over-call for cold starts.