Identifying cause of delayed response headers without disclosing private data

The situation

Public share pages were experiencing significant delays in response headers, with some requests taking tens of seconds to complete. The issue was not affecting the homepage, and recovery requests were not able to identify the cause of the delay. The current system checks for grant admission for every page and file read, including revocation, and cannot reach a client that cancels. The goal is to identify the cause of the delay without disclosing private share data or weakening current grant checks. The system awaits a link-index lookup, live-grant owner, byte preparation, and page rendering before sending headers.

What they weighed

• Time each generic pre-header stage with identifiers excluded, then correct the slow stage established by live logs.

  Chosen

• Cache grant or namespace data immediately to try to hide the stall before knowing its cause.

What they decided

Time each generic pre-header stage with identifiers excluded, then correct the slow stage established by live logs.

Why

The chosen option was selected because it allows for the identification of the slow stage without disclosing private data or weakening current grant checks. Canceled share requests cannot return data, and current evidence cannot assign the no-header stall to a grant or scheduler. Generic stage-only logs can identify the pending pre-header await without disclosing a recipient or weakening revocation. This approach preserves the live grant and makes no speed claim until a real slow event is traced.

The first step

Finalize privacy-safe stage timing in the existing generic share route, fix the index error boundary, and split logo access from byte preparation. Run focused tests and build, then publish through the current main and use live logs to locate a reproduced slow stage before changing its owner.

How they would know it worked

A reproduced slow public share has a stage-only waiting and ended event, ordinary and revoked shares retain their previous outcomes, and no private link, person, or file data appears in logs.

How it turned out

Not known yet. The result is added here when it comes in.