LiveView race conditions: more since LV 1.0?

I am noticing race conditions that corrupt LiveView’s state of affairs, and this seems to be particularly happening since LV 1.0.

Examples:

  • Fill in an input (say “company”) or two. When filling in a third one (say “amount”), then “company” gets cleared on the client, although there is no that is clearing it, and indeed LV still believes that this field to have a value. Thus on “change”, the params received all remain with the previously entered value. This state of corruption seem to worse with more inputs being filled / (and wrongly cleared). 100% reproducible in a cypress test, and adding a small delay between the inputs make the bug disappear.
  • Starting an upload with autostart and then triggering a “change” event on a form used to work before LV 1.0, but after it the upload wouldn’t start. Starting the upload just after triggering the “change” event bypassed the issue. Again, this was 100% reproducible.

Anybody else noticing similar? Should this be considered a bug in LV?

I can see a place where such behaviour would be intended, so I’d say yes and consider those better posted on the issue tracker on github.

Sir, you probably have a bug in your code.

First thing I’d check is if your inputs do not have the same ID, or are not in containers of duplicate IDs.

I believe LV warns about it on the console.

I had the issue with inputs being cleared, but I think that was in a 1.0 release candidate. Updating to 1.0 fixed it for me.

1 Like

Do you have a form struct - to_form(%{}). If yes you need to update it in the phx-change event.
The fields need to be tied to the form struct for ex

<input name={@form[:company].name} value={@form[:company].value}>

That way you you won’t lose the changes.

Can you show your code?

FYI, bug report regarding uploads with link to a repo here: LiveView 1.0 introduced update issue with autostart uploads · Issue #3647 · phoenixframework/phoenix_live_view · GitHub

The input clearing is turning out to be difficult to simplify. It’s in a very complex form. It takes 4 inputs to be previously filled for a fifth one to be mistakenly cleared. If I add some delay in cypress between the inputs filling, the bug also disappears. It seems extremely challenging to produce a minimal reproducible example :cry:.

Even the auto-upload issue wasn’t easy to pinpoint. Hopefully they are related :crossed_fingers:. Details in this issue: LiveView 1.0 introduced update issue with autostart uploads · Issue #3647 · phoenixframework/phoenix_live_view · GitHub

Yes, I have experienced at least one race condition in my code after updating to 1.0.

I have a “dynamic” tabs component in my code that will contain a list of opened tabs, in some very specific cases, after closing a tab, LV will re-add it back in even though the server doesn’t have that tab in its state anymore. It is something related to push_patch that messes it up as far as I understood it.

The issue is that I could only reproduce it with my full code, because even if I just removed/changed a simpler version the content of the tab, then the bug would go away, hinting that it is a race condition.

Since I couldn’t create a small project that was reproducing the issue, I kinda worked around it using streams and moved on.

3 Likes

Update: fixed! use regular DOM patching when unlocking cloned trees by SteffenDE · Pull Request #3652 · phoenixframework/phoenix_live_view · GitHub

Thanks @steffend!

3 Likes