trubo:load gets triggered twice when GET request is a redirect 302

Hi, is this on purpose and if so, how can I make sure that the first call doesn’t do anything?

I created a test where you can test this problem

Start there the server bundle exec rails s and open the page localhost:3000. You will see a link that points to page 1 but then gets redirected to page 2. On the first page load, you will see an alert which you then will see twice after clicking on this link.

[feliperaul]

I just hit this and I can’t think of a way to escape as it is.

Our page also contains javascript that as soon turbo:load fires, it will dispatch JS requests for analytics, counting 2 views while only one actually happened.

But that’s not all. We have pages that once turbo:load fires, dispatch JS POST requests that update the model’s lock_version (Rails’s OptimisticLocking).

Since turbo:load is firing twice, the app totally breaks because when the response’s HTML actually renders on the screen, the “ghost” render that was previously invoked by Turbo fired the JS POST requests updating the lock_version unadvertly, so the user already has a stale version in his screen.

The browser never triggers ‘DOMContentLoaded’ twice after receiving a 302 or 303 response, but Turbo is.

This has nothing to do with idempotency; the code is totally idempotent as it is.

Lastly, there’s the performance penalty: the browser is initializing a huge Vue application twice, making JS requests to fetch data, and so on. If it was only this, and they were only GET requests, it would be a minor bug, but considering the non-idempotent requests JS can make once turbo:load gets fired, this is actually a major problem on pages that can be loaded after a redirect.

[joker-777]

@feliperaul Amazing!