> Begin of the insertion_ThisEnd of the insertion Begin of the deletion *ThisEnd of the deletion was generated by AI during Begin of the insertiontriage._End of the insertion Begin of the deletion triage.*End of the deletion

## Problem

The global `turbo:frame-missing` handler unconditionally visits the failed response URL. When a page shell loads successfully but its lazy Turbo frame consistently fails, this recovery can create an infinite page reload loop.

This was observed while investigating [AGILE-434](https://community.openproject.org/wp/AGILE-434). The milestone filter caused a database error in the Backlogs frame request. Fixing that query removes one trigger, but leaves the shared recovery defect in place.

## Steps to reproduce

1. Begin of the insertion End of the insertion On an affected 17.9 build, open a Begin of the insertionproject'sEnd of the insertion Begin of the deletion project'sEnd of the deletion Backlogs page with the Is milestone filter available. Begin of the insertion

End of the insertion Begin of the deletion
End of the deletion 2. Begin of the insertion End of the insertion Open All filters and add Is milestone. Begin of the insertion

End of the insertion Begin of the deletion
End of the deletion 3. Begin of the insertion End of the insertion The `backlogs_container` request fails with HTTP 500 and a response without the expected frame. Begin of the insertion

End of the insertion Begin of the deletion
End of the deletion 4. Begin of the insertion End of the insertion Observe the page repeatedly reconstructing on staging. Begin of the insertion


End of the insertion Begin of the deletion

End of the deletion For a regression test independent of the milestone query, use a page whose shell returns HTTP 200 and contains a lazy frame whose endpoint consistently returns HTTP 500 without the expected frame.

## Actual behavior

1. Begin of the insertion End of the insertion The failed frame response raises `turbo:frame-missing`. Begin of the insertion

End of the insertion Begin of the deletion
End of the deletion 2. Begin of the insertion End of the insertion The global handler prevents the default behavior and calls `visit(response.url, {})`. Begin of the insertion

End of the insertion Begin of the deletion
End of the deletion 3. Begin of the insertion End of the insertion The full-page request renders the page shell successfully. Begin of the insertion

End of the insertion Begin of the deletion
End of the deletion 4. Begin of the insertion End of the insertion Its lazy frame makes the same failing request, restarting the cycle. Begin of the insertion


End of the insertion Begin of the deletion

End of the deletion The original error is obscured by repeated navigation, the page becomes unusable, and additional requests continue without user input.

## Expected behavior

Begin of the insertion* End of the insertion Begin of the deletion -End of the deletion A failed frame request terminates in a stable, understandable error state. Begin of the insertion

* End of the insertion Begin of the deletion
-End of the deletion The application does not automatically revisit the same failing page or repeat requests indefinitely. Begin of the insertion

* End of the insertion Begin of the deletion
-End of the deletion Users can recover through an explicit action without losing the rest of the usable page unnecessarily. Begin of the insertion

* End of the insertion Begin of the deletion
-End of the deletion Successful frame navigation and any intentional full-page redirects continue to work. Begin of the insertion


End of the insertion Begin of the deletion

End of the deletion ## Technical context

The unconditional fallback is in [frontend/src/turbo/setup.ts](https://github.com/opf/openproject/blob/release/17.9/frontend/src/turbo/setup.ts), in the `turbo:frame-missing` listener.

Remove the unconditional automatic revisit and determine the appropriate error presentation using the existing Turbo/application conventions. Review affected callers, including intentional redirects such as authentication flows, before removing shared behavior.

Add regression coverage for a consistently failing lazy frame, a successful response missing the expected frame, and supported intentional navigation. Assert that requests stop and that the page remains in a stable state.

## Evidence and scope

Observed during investigation on 2026-09-15. Local `release/17.9` at `9a0c3fd503e38abd33fbaeeaf934a3bad9360e4d` reproduced the initiating HTTP 500 (`PG::AmbiguousColumn`); staging demonstrated repeated page reconstruction. Local development renders a different exception response, so the full production-style loop was not reproduced identically there.

This is a separate Bug in shared error recovery. The Backlogs SQL repair in Begin of the insertion#AGILE-434End of the insertion Begin of the deletion AGILE-434End of the deletion and the other Backlogs filter fixes remain independent. No target version is proposed here. Begin of the deletion
End of the deletion