@packagethief thanks for reviewing.

If the requesting frame is gone, there's no reason to process its response, and doing so can cause unintended side effects like the one you've described.

Yes, exactly. From a user perspective I think the main issue is that the session gets reverted even when they've navigated away from the page containing the turbo-frame. E.g. a user taps "Log out", they're navigated to a different page, the turbo-frame request then completes, and they're logged in again without them knowing.

One thing to consider: this handles the case where the frame is explicitly removed, but the race could still occur if the frame remains in the DOM. I'm not sure there's much Turbo can do about that scenario, but I think eliminating the disconnect case is still valuable.

When working on a workaround I considered:

1. setting the disabled attribute, which unfortunately doesn't abort in-flight requests
2. removing/setting the src attribute*, which will only abort a request if the src is present
3. manually cancelling the frame's current request (e.g. frameElement.delegate.currentFetchRequest.cancel()), however currentFetchRequest is a private property

I think it'd make sense that in-flight requests are aborted if the frame becomes disabled or if the src is blank.

can you think of a way to test this behavior? Seems kind of tricky.

Yes, it's tricky! It might be handy for testing if currentFetchRequest were made public, then we could assert that cancel() is called on it?

*In the end I set up a /noop endpoint which does not set cookies, and set the src of any in-flight turbo-frames before the next page renders:

addEventListener('turbo:before-render', () => {
  document.querySelectorAll('turbo-frame[busy]').forEach((element) => {
    element.src = '/noop'
  })
})