When returning from the show screen to the index screen, has_many models cannot be manipulated

[yuki-yogi]

Describe the bug

• When returning from the show screen to the index screen, has_many models cannot be manipulated
• Occurs in models specified with has_and_belongs_to_many and has_many: **, through: **.

Steps to Reproduce

Steps to reproduce the behavior:

1. Go to https://avodemo.com/avo/resources/projects/39
2. Click some user
3. Perform Back in Browser
4. Perform Paging and sorting of user
5. See error

Expected behavior & Actual behavior

User can be reordered and paged even after viewing the User details screen and returning to it in the browser.

System configuration

Avo version: 3.5.1

Rails version: 7.1.3.2

Ruby version: 3.2.0

License type:
This is occurring at https://avodemo.com/avo/resources/projects/39.

Are you using Avo monkey patches, overriding views or view components?

• Yes. If so, please post code samples.
• No

Screenshots or screen recordings

This is occurring at https://avodemo.com/avo/resources/projects/39.

has_and_belongs_to_many_error.mp4

Impact

• High impact (It makes my app un-usable.)
• Medium impact (I'm annoyed, but I'll live.)
• Low impact (It's really a tiny thing that I could live with.)

Urgency

• High urgency (I can't continue development without it.)
• Medium urgency (I found a workaround, but I'd love to have it fixed.)
• Low urgency (It can wait. I just wanted you to know about it.)

[adrianthedev]

This is an ugly one.
Not sure what happens.
We'll have a look.

[yuki-yogi]

@adrianthedev
Thank you for confirming so quickly❤️ We frequently use the has_many: **, through: ** association, which has led to many inquiries from users. This has been a significant challenge for us..

[Paul-Bob]

When browser back button is pressed page loads from turbo cache. Still figuring out why all turbo links stop working...

Noticed that adding <meta name="turbo-cache-control" content="no-cache"> to application.html.erb solves the issue, forcing all page to load when hit the back button. This have some inconveniences like performance and current page inside frames is not saved, but it also guarantees that all data is updated.

@yuki-yogi the best solution that we can suggest right now is to disable turbo cache control on head or pre_head partials https://docs.avohq.io/3.0/eject-views.html#prepared-templates

Still researching the cause and a better solution

[yuki-yogi]

@Paul-Bob
Thanks for sharing your workaround.
Using no-cache also loses screen state and destroys paging and filter state, so I will consider this carefully!

[nrgbistro]

Build off this because I think it's the same root cause. When I run an action after using the back button in my browser, query.size becomes 0 no matter how many rows I select. Steps to reproduce:

1. Run action from index page, works as expected
2. Click on show page for a row
3. Navigate back to the index page using the back button (tested using latest version of Chrome)
4. Select rows and run (any) action
5. See the action query params in the url: http://localhost:3000/path/to/resource/actions?action_id=Avo::Actions::ActionName, query.empty? == true.

This is a severe issue because it's causing the action to fail without warning to the user unless the action is set up to detect if the query is empty, which should never be true under normal circumstances. The only indication of failure is the url query params and the action modal not closing.

[Paul-Bob]

@nrgbistro it's caching-related but the source issue is different, I'll create a new issue with your comment.

[yuki-yogi]

I have confirmed that the same issue occurs with Avo v3.11.6 · Rails 7.2.0.

https://avodemo.com/avo/resources/projects/35

1. Click to open the user's detail page
2. Use the browser's back button to return
3. Try to paginate to the next page

Pagination doesn't work properly.

4. Click the User again to open the detail page
5. Use the browser's back button to return
6. For some reason, it has paginated to the next page

https://discord.com/channels/740892036978442260/1274908901313347644/1275026252817764373

[adrianthedev]

@Paul-Bob can you please timebox this for one hour this week to maybe identify why things are failing on the back action?

[Paul-Bob]

@yuki-yogi we found the issue. It's a turbo issue related to revisiting a frame that was lazy-loaded. More context here hotwired/turbo#886

There is already a PR to fix it and this issue should be fixed after the PR gets merged.

I noticed some temporary fix suggestions on the original issue and made this PR #3160 which seems to fix the problem temporarily.

[yuki-yogi]

@Paul-Bob Thank you so much for your prompt confirmation and response! I truly appreciate it.