Possible race condition with latency/async assigns (components being destroyed when still on the page)

sevenseacat commented 2 months ago

Environment

Elixir version (elixir -v): 1.15.4-otp-26
Phoenix version (mix deps): 1.7.14
Phoenix LiveView version (mix deps): 1.0.0-rc.6 (also tested on main at 440fd0460405c57f61fcc7457ea9f80ff56f1135)
Operating system: macOS Sonoma
Browsers you attempted to reproduce this bug on (the more the merrier): Edge, Firefox, Safari, Chrome
Does the problem persist after removing "assets/node_modules" and trying again? Yes/no: yes

Actual behavior

This is a tricky one because it appears to be a race condition somewhere, when also having a few levels of nested live components and a bit of latency.

Reproduction

I've managed to replicate something very similar in a single-file app - https://gist.github.com/sevenseacat/d7629834278a9bbede70c6c2d3b56e73

Run code with elixir bug_liveview_no_component_for_cid.exs
Visit http://localhost:5001
Enable some latency, eg. liveSocket.enableLatencySim(100)
Click one of the second-level buttons to change the content
Click one of the top-level buttons to change the page
The second-level tabs appear to no longer respond to clicking, until another top-level button is clicked (or the page reloaded)

The CID for the live component rendering the second-level buttons has been destroyed by the client, so it no longer listens for events at all.

Actual issue

The reproduction is a bit different to what I'm seeing in my actual app, but I'm hoping a fix for one will also fix the other. 🤞

In my real app, the second-level buttons are still clickable, the server sends back the content to render, but the child components in the tabs have already been destroyed by the client (eg. AdvisoriesTable, amongst others). This leads to a "no component for CID xxx" error when LV tries to update the DOM with the new content.

It's kind of like this bug https://github.com/phoenixframework/phoenix_live_view/issues/1848 but removing the tables didn't make it go away :(

Expected behavior

After clicking a first-level button, the second-level buttons should still be usable, to toggle tabs for the newly-selected element.

SteffenDE commented 2 months ago

In your real app, do you experience this as well if you don't use the latency simulator? I think that the specific issue here only happens with the latency simulator enabled.

mindok commented 2 months ago

@SteffenDE - yes, we do. The customer is on a remote site in north west Australia and ping times are typically 70-120ms back to our hosting provider on the east coast of Australia. We use the latency simulator to reproduce locally. BTW - I'm working with @sevenseacat on this. We've looked at how to reduce the LiveComponent nesting to reduce the impact, but we can only take it so far before we lose core functionality.

EDIT: And yes, to confirm, the issue only arises when there is reasonable latency between browser and server. When developing locally we didn't see the issue. It was only when it was put in front of customers!

sevenseacat commented 2 months ago

We do see it very occasionally in dev, but at a different part of the app (when clicking on the first-level tab). I'm not entirely sure that the reproduction is the same bug, but if it can fix another race condition bug, that's good too!

sevenseacat commented 2 months ago

As it seems to relate to async loads/latency, we've removed the async loading from our app and the problem appears to be resolved. Nonetheless it would be good to see issues around it ironed out!

chrismccord commented 1 month ago

As @SteffenDE wondered, this was only a bug in the latency simulator, which wasn't accounting for incoming latency so messages were being applied out of order. If you can further isolate your production issue, I'd be happy to take a look as it sounds like something else must be going on if you're seeing issues outside of the latency sim. Thanks!

phoenixframework / phoenix_live_view