[Bug] Discover restores a removed market when an in-flight refresh finishes

[kapelame]

Removing the last market source clears Discover, but a refresh response that was already in flight can repopulate its listing afterwards. The configured sources remain empty and selected remains null; only listing comes back.

Versions and validation scope

• Released dsh-v0.2.1-rc.3: commit 1f81c047fc48fa190a683e469daa699857e9afe8.
• Current master checked on 2026-10-26: 22ddee3792402c3e70ec5f86a63c3e3e895a2f60.
• macOS arm64; master tested with Node.js v26.10.0 (its engine is >=24.9.0); release tag tested with Node.js v22.22.2 (within its supported engine range). Both use tsx@4.22.4 and published @deepseek-ai/dsh-client-store@0.2.1-rc.3.
• I executed unchanged DiscoverController source from both commits with controlled remote Promises, and separately reproduced the release behavior with the actual published PluginMarket Host and a delayed loopback HTTP index. No complete desktop GUI or live-network incidence was measured.

Reproduction

1. Configure one index A and load Discover successfully.
2. Refresh A, holding that pluginMarket.search() response pending.
3. Remove A and let setIndexes([]) and the following listIndexes() complete.
4. Confirm the state is indexes: [], selected: null, listing: null.
5. Complete the response from step 2.

Expected: the response belongs to a removed source and is ignored; Discover stays in its empty/add-first-source state.

Actual: listing.url becomes A again. A successful response produces status: 'ready'; a failed response also restores the old listing with status: 'error'.

Both the release-tag source and current-master source reproduced this in 10/10 controlled success cases and 10/10 controlled error cases. Those counts describe the deliberately controlled ordering, not normal-user incidence.

Example after the late success:

{
  "indexes": [],
  "selected": null,
  "listing": {
    "url": "https://market.example/index.json",
    "status": "ready"
  }
}

Host-backed release reproduction

The published @deepseek-ai/dsh-plugin-market@0.2.1-rc.3 fetched a real local HTTP index. I held its second HTTP response, removed the source, and verified the actual Host's listIndexes() returned []. Releasing that HTTP response still restored the removed index's plugin in the release-source client. A subsequent real Host search returned plugin-market/unknown-index, while the client retained the old listing; reloading the source list cleared it.

This integration used real Host fetch/parse-worker/search/setIndexes code. Settings was a test service that applied the validated source change via updateVolatile; installed-bundle inventory was an empty fixture, and RemoteResult calls were adapted directly. It did not exercise disk persistence, WebSocket transport, Chromium, or the full GUI.

The existing packages/client/ui-plugin-market/tests/market-store.client.spec.ts helpers can demonstrate the missing case:

it('ignores a refresh that finishes after its last source was removed', async () => {
  const { face, market, snapshot } = setup([{ url: A }])
  face.ensure()
  await vi.waitFor(() => { expect(snapshot().listing?.status).toBe('ready') })

  const slow = Promise.withResolvers<{ ok: true; value: MarketSearchResult }>()
  market.search.mockImplementationOnce(() => slow.promise)
  face.refresh()
  face.removeSource(A)
  await vi.waitFor(() => {
    expect(snapshot()).toMatchObject({ indexes: [], selected: null, listing: null })
  })

  slow.resolve({ ok: true, value: listing(A, 'late') })
  await new Promise(resolve => setTimeout(resolve, 0))
  expect(snapshot().listing).toBeNull()
})

The standalone harness executes this ordering against both checked sources and also exercises an ok: false result. I have not run the repository-wide test suite. Two passing controls isolate the edge case: deleting a source without a pending refresh stays empty, and deleting A while B remains configured correctly ignores A's late response.

Cause and impact

In the release source, loadIndexes() clears listing when selected === null, but it does not invalidate the outstanding listing read. The asynchronous load() only checks listingRead, so it can still call settle() afterwards. The same paths remain on current master, at lines 309 and 333 respectively.

The source-management menu remains available while a listing loads, and its Remove button is disabled only while a source save is running, so the refresh → manage sources → remove sequence is reachable through the declared UI controls. The visible effect follows from DiscoverSection choosing the empty state by listing === null and otherwise rendering Browser; it does not hide that restored listing because selected and indexes are empty. I checked that rendering branch in both source versions, but did not run a full GUI rendering test. This report does not claim the source was re-added to settings or that a plugin was installed automatically.

Incrementing the listing-read generation when clearing the last selection prevented the restoration in a scratch-copy control (20/20 controlled cases). That appears to be the missing invalidation; no repository patch or PR is included.

Recovery and limits

In the controlled client test, calling ensure() again on the same controller leaves the restored listing unchanged. Another refresh reports plugin-market/unknown-index and retains the old listing. Re-reading the source list (reload()) or constructing a new controller restores the empty state. These are API-level checks; I did not test clicking a stale plugin's Install button or claim that deleting a source can be bypassed.

Duplicate and fix checks

On 2026-10-26 I fully paginated 19 related public Discussion searches (1,261 unique discussions, 3,233 comments, 721 replies), including open and closed results. I found no report of this same last-source/late-response case. Nearby reports #10869, #10786, and #10538 concern update actions, third-party market lifecycle, or hung plugin operations instead. Public all-state Issue/PR searches returned no visible entries; internal or inaccessible PRs could not be checked. The fixed master source and its path history still retain the clearing branch above.

AI assistance

This report was prepared with an AI assistant. The stated results are actual isolated script runs; the full desktop UI was not driven or captured. No real user profile or repository source was modified.

[PerryLink]

settle() writes the listing without checking its source. Nothing else does.

I read this against 22ddee3. loadIndexes() clears listing at packages/client/ui-plugin-market/src/client/market-store.ts:309, but load()'s only staleness check is read !== this.listingRead (:333), and loadIndexes never bumps that counter on the empty-selection branch. So the pending read still owns its generation, reaches settle() (:390), and settle calls this.patch({ listing, indexes }) (:400) with the url it started for — no check that the url is still configured. patch spreads the current snapshot, so indexes: [] and selected: null survive and only listing comes back. That is exactly your JSON.

The gap is one branch wide: selected !== this.state().listing?.url starts a new load(), which bumps listingRead and invalidates the older read. Only selected === null clears without invalidating anything.

Fix, in loadIndexes:

if (selected === null) {
  this.listingRead++
  this.patch({ listing: null })
}

It has to sit in the same synchronous block as the clearing — anything after an await is too late. A url guard inside settle would also work as a second belt, but the counter bump matches how indexRead already guards loadIndexes (:293–:296).

Your spec sketch matches the existing helpers: setup() at tests/market-store.client.spec.ts:42 returns { face, market, snapshot }, and face.removeSource is the real action (:218). Keep the setTimeout(resolve, 0) before the final assertion — settle runs after the awaited page, so the store settles on the microtask queue, not synchronously after resolve.