Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

NuGetBrowserPanel.waitForInitialLoad() resolves on a load that never ran

Aperta
  • Qualcosa non va?
#293 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
65/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript, vscode
Ambito
desktop, devtools, tooling

Direzione di ricerca

The bug is in src/editors/vscode/src/nuget-browser.ts lines 159-173, in the initialLoad method. Start by reading the method and understanding the flow when selectedTargetId is undefined. Look at the callers of waitForInitialLoad to see how they expect to be notified. The fix involves modifying the promise resolution logic and adding a test for the unresolved target state as per the spec. Check the logs in the issue for the exact sequence of events.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

NuGetBrowserPanel.waitForInitialLoad() resolves successfully in a state where the browse tab was never populated and no search was ever issued. Callers cannot distinguish "loaded, and there is nothing" from "never loaded anything".

Filed separately from the browse tab is populated on initial load flake at the request of the agent driving #291: the two have opposite signatures and one would mask the other. The flake makes that test time out; this makes it fail fast. If this lands while the flake is live, the fast failure hides the slow one and the wrong cause gets chased.

Cause

src/editors/vscode/src/nuget-browser.ts:159-173:

private async initialLoad(): Promise<void> {
  await this.loadTargets();
  ...
  if (this.selectedTargetId !== undefined) {
    await this.loadInstalledPackages();
    await this.performSearch('');
  }
  this.updateContent();
  log.info('NuGetBrowserPanel: initial load complete');
}

When loadTargets() leaves selectedTargetId undefined, the installed-package load and the browse search are both skipped, updateContent() renders an empty tab, and the method logs initial load complete and resolves. waitForInitialLoad() awaits that same promise, so it reports success.

Evidence

From vsix-logs-win32-workspace, run 35800116593, SharpLsp.log. Note the completion arriving before any search, with packages=0:

00:19:05.524 NuGetBrowserPanel: creating panel for PropsProj
00:19:05.524 NuGetBrowserPanel: rendering tab=browse packages=0 installed=0 loading=0
00:19:05.525 nuget/lsp: fetchTargets workspace=...
00:19:05.525 NuGetBrowserPanel: initial load complete        <-- resolves here, packages=0
00:19:05.525 nuget/lsp: fetchInstalled target=props-1
00:19:05.526 nuget/lsp: searchPackages target=props-1 query=""
00:19:05.526 NuGetBrowserPanel: search returned 1 results
00:19:05.526 NuGetBrowserPanel: rendering tab=browse packages=1 installed=0 loading=0
00:19:05.526 NuGetBrowserPanel: initial load complete        <-- and again, packages=1

initial load complete is emitted twice for the same logical load, and the first one is the promise's resolution with an empty tab.

Why it matters beyond the test

The panel is a user-facing webview. A user opening the NuGet browser on a project whose target resolution has not settled gets a permanently empty Browse tab with no spinner (loading=0) and no error — the panel believes it finished. That is the same defect class as [SE-ACTIONS-BUILD] (an invisible build) and the blank Test Explorer tree: the failure path produces the same observation as success.

Suggested fix
  1. initialLoad() MUST NOT report completion for a load it did not perform. When selectedTargetId is undefined, that is a distinct outcome — render an explicit empty/unresolved state, and make it observable.
  2. Emit initial load complete exactly once per load.
  3. Give waitForInitialLoad() a result callers can branch on, rather than a bare Promise<void> that resolves identically in both cases.
  4. Cover it with a test that opens a panel with unresolved targets and asserts the panel reports the unresolved state rather than silent emptiness — per [NUGET-BROWSER-SPEC].
Note

Found while diagnosing the Windows workspace leg timeout, which is a different bug: that one is waitForInitialLoad() blocking on a live azuresearch-usnc.nuget.org query inside a 15s budget. Both were invisible in the mocha output and only appeared in the uploaded VSIX log artifacts.

Lingua principale
TypeScript
Stelle
132
Fork
5
Merge medio
9h 20m
PR unite (30g)
51

Preparare l'ambiente

Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Nimblesite/SharpLsp

Tutte le issue di Nimblesite/SharpLsp

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.