investigate(demo): synthetic downloads lose requested names in clean Chromium

[lamemustafa]

In clean Chrome for Testing 151.0.7922.34, the synthetic reviewer demo produced ten completed, nonempty files, but the browser saved them with generic names instead of the requested demo folder and names. That makes the demo index harder to use because its requested names do not match the saved files.

This was observed during local Store-candidate QA. File contents were synthetic and correct; the manifest and exception report matched the demo, and clear-data plus a full browser restart removed the stored summary. No real documents were used. The behavior was observed with Playwright download interception disabled and native download settings restored, but a separate UI-only reproduction was not completed. Treat automation influence as unresolved, not as a proven product cause.

One code path to check: src/background/synthetic-demo.ts releases its filename reservation as soon as downloads.download() resolves. The filename guard expects the reservation to survive until a terminal download observation. The current fixture fires filename determination before that promise resolves, so it does not cover a late callback. This is a hypothesis to test, not a confirmed diagnosis. The synthetic-demo code is unchanged between 11cc788 and 1b64fab.

Priority: P2. Scope is demo organization and index consistency; these observations do not establish corruption, a privacy failure, or failure of real downloads.

Acceptance:

• Reproduce in a clean browser without download-protocol overrides.
• If confirmed, retain requested demo names and folder through download completion, including a delayed filename callback.
• Confirm the downloaded index matches saved files and clear-data/restart behavior still passes.

[lamemustafa]

The hypothesis in the issue is confirmed at the code level, against the contract the reassertion module states about itself. This does not replace the live reproduction the acceptance criteria ask for, but it does move this from "one code path to check" to "the code contradicts its own documented contract."

src/background/pack-download-filename-reassertion.ts:36-37 states the protocol:

This is immediate event correlation, not run truth: callers reserve just before download() and release at its terminal observation.

src/background/synthetic-demo.ts:45-55 does not follow it:

const downloadId = await browser.downloads.download({ ... });
reservation.bind(downloadId);
downloaded += 1;
} finally {
  reservation.release();
}

The finally runs as soon as downloads.download() resolves, which is when the download has been accepted, not when it has terminally settled. onDeterminingFilename fires independently and routinely after that point. By the time it does, release() has already deleted the entry from both requestedFilenamesByUrl and the id map, so the listener has nothing to re-assert and Chrome falls back to its own generated name — which is exactly the reported symptom: correct, nonempty contents saved under generic names outside the requested Pack-Demo/ folder.

That also explains why the existing fixture passes. As the issue notes, it fires filename determination before the download() promise resolves, so the reservation is still live. The ordering that fails in a real browser is the one the fixture never produces — the fixture encodes the assumed ordering rather than the observed one.

Two things this does not establish, and I would not close the issue on it:

1. It does not rule out automation influence. The observation was made with Playwright interception disabled, but a UI-only reproduction is still outstanding and the timing that makes this visible is precisely the kind a harness can perturb.
2. It says nothing about real downloads. This defect is in synthetic-demo.ts only. The filed-return acquisition paths bind and release their reservations separately, and the target-bound download evidence that gates completion is a different mechanism entirely — so the privacy and correctness assessment in the issue stands unchanged.

Suggested shape for the fix, when the live repro is done: release at the terminal download observation rather than in a finally after download(), and build the regression fixture from the observed ordering — filename determination arriving after the download promise resolves — since that is the case with no coverage today.

[lamemustafa]

Partly addressed in #365 — and deliberately only partly, because the acceptance criteria here ask for something #365 does not provide.

Fixed: the protocol violation. pack-download-filename-reassertion.ts documents that callers "release at its terminal observation"; synthetic-demo.ts released in a finally as soon as downloads.download() resolved. The reservation now outlives onDeterminingFilename via a bounded whenAnswered(), and the same early release on the data-URL branch of download-prompt-probe.ts — found while confirming this one — is fixed with it.

Also fixed: the fixture. It fired the listener synchronously inside the download() mock, so the reservation was always still live and the test passed whether or not the reservation outlived the promise. Rewritten to the ordering a real browser produces; against the unfixed caller it now reports expected [] to have a length of 10, i.e. the browser was told nothing for any of the ten files.

Not established, and this issue should stay open for it: that the above explains what you observed. The acceptance criteria ask for a reproduction in a clean browser without download-protocol overrides, and that has not been done. Two things remain genuinely unresolved:

1. Automation influence is still not ruled out. The original observation was made with Playwright interception disabled, but a UI-only reproduction was never completed, and the timing that makes this defect visible is exactly the kind a harness can perturb — in either direction.
2. A protocol violation found while looking for a cause is not thereby the cause. It is a real defect on its own terms, which is why it is fixed rather than held. But this repository has a recorded habit of writing a plausible mechanism into a spec and having the next probe falsify it, and the honest position is that the naming behaviour you saw has not yet been reproduced against the fix.

What would close this: load the built extension in a clean profile, run the demo with native download settings and no automation, and confirm the ten files land in Pack-Demo/ under the requested names, with the index matching. If they do, that closes it. If they do not, the remaining cause is somewhere else and #365 has removed one confound from the search.

Worth noting for whoever runs it: this is cheap to fold into the full-year live session rather than staged separately — same clean profile, same native download settings, and the demo needs no portal session at all.

[lamemustafa]

The hypothesis in this issue was implemented in #365 — what remains is the verification

This issue named one code path as a hypothesis: src/background/synthetic-demo.ts released its filename reservation as soon as downloads.download() resolved, so a late onDeterminingFilename callback found nothing to re-assert.

That is now the code on master (1b512ee), and the comment at synthetic-demo.ts:53-58 cites this issue by number:

reservation.bind(downloadId);
downloaded += 1;
// `downloads.download()` resolves when the download is accepted, not when Chrome has
// asked what to call it. Releasing here -- which is what the `finally` used to do on its
// own -- dropped the reservation before `onDeterminingFilename` fired...
await reservation.whenAnswered();
} finally {
  reservation.release();
}

whenAnswered(timeoutMs = FILENAME_DETERMINATION_WAIT_MS) defaults to 500 ms, short-circuits to false when no onDeterminingFilename listener is installed, and release() settles an in-flight wait — so the loop cannot hang on a browser that never asks.

What that does and does not settle

Does not settle: whether this was the cause. This issue was careful to say so, and the caution still stands — "treat automation influence as unresolved, not as a proven product cause". The fix addresses a real ordering defect that was demonstrably present; it does not prove that defect produced the ten generically-named files.

Does settle: the acceptance criteria are now down to the last two, and the first is a QA step rather than a code change:

• If confirmed, retain requested demo names and folder through download completion, including a delayed filename callback — implemented, with unit coverage in fix(download): hold the filename reservation until determination answers #365
• Reproduce in a clean browser without download-protocol overrides — now a confirmation run rather than a diagnosis run: does the demo still lose its names on master?
• Confirm the downloaded index matches saved files and clear-data/restart behavior still passes

If the clean-browser run now saves into Pack-Demo/ with the requested names, this closes and the cause is established retroactively. If it still does not, the cause is elsewhere and this issue becomes genuinely more interesting, because the obvious candidate has been eliminated.

Worth running against the same Chrome for Testing build named above so the comparison is like for like.

Read from the code on master; no browser run performed.