Fix bounded connection headroom for owner recovery Web UI - #5
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Scope
Web recovery alone retains at least eight transport sockets, without raising the private request/restoration concurrency limit or changing ordinary DAV limits. Authentication, selected-owner authority, timeouts, cleanup, upstream UI and source pins remain unchanged.
Exact candidate: 63bba5d (tree 3856e52886312517484428236d9e2d5f361afbd9), based on main c81980d.
Original failure and focused evidence
Core run 36935715873 on a7d244a720cf4e08475255e30bbc641b4e35fc2d failed at original Files unlock after protected-peer restore/catalog/SDK reads. Private/topology cleanup and unchanged host state passed. Original failure remains failed; the closed CI report did not retain individual HTTP connection events.
A separate local original-Web8 / installed Firefox 140.16 diagnostic reproduced the same unlock failure using synthetic metadata and the actual maxConcurrent=2 configuration: six allowed connections filled, 20 connections dropped, both login fetches failed before the session HTTP handler. A transport-only counterfactual at eight connections passed (peak seven, zero drops). The unmodified candidate server then passed the same original UI wrong-token denial, valid unlock, selected-file navigation and no-write-action checks. This diagnostic did not download or restore any private file and is not peer-storage proof. Fresh profiles/private staging were removed.
The new real loopback HTTP regression fails on the parent with ECONNRESET and passes on this candidate. Three targeted tests passed, including unchanged ordinary DAV and web-mode private concurrency/deadline behavior. Diff checks passed.
Draft pending a fresh joined original UI/protected-peer storage trial. No merge is requested yet; no complete server-independent OpenCloud claim.