What's happening
wait_for_download (crates/flowproof-adapters/src/web.rs:2929-2955) snapshots
"what files already exist" as its baseline inside the function, at call time —
not at browser launch, and not at the click/step that actually triggers the
download. If the download completes and the browser renames the file off
.crdownload in the gap between the triggering step returning and the Wait until the download completes as <name> step actually invoking
wait_for_download — realistic for small/fast exports, or just a slow step
dispatch — the file is already sitting in the baseline snapshot when the poll
starts. It's therefore never seen as "new," and the step spins to its full
timeout and reports a failure even though the download genuinely succeeded.
There is no unit or integration test for wait_for_download at all — it needs
a real browser, and isn't covered even in the gated e2e diff that introduced
it (#483).
If we don't fix it
Any flow with a fast export (the common case, e.g. examples/fiori/purchase-info-records-report.flow.yaml's
Excel export) is flaky in exactly the direction this project cannot afford:
a real, successful download reported as a failure. On a slower CI runner this
may not reproduce; on a fast one or a small file it will, intermittently.
If we fix it
The wait step becomes reliable regardless of how fast the download completes
relative to step dispatch.
Suggested direction
Track already-claimed download files as persistent driver state (populated at
launch or at the point downloads are enabled), rather than re-diffing the
whole directory fresh on every wait_for_download call. That keeps the
"exactly one new file" contract for the sequential-download case (#483's
stated goal) while closing the fast-download race.
Before closing
Needs a regression test for wait_for_download itself — something that
proves a file present in the directory before the wait call, but written by
the download this step is waiting for, is still recognized. A real browser is
needed to exercise this end to end; at minimum, extract the "which files
count as new" logic so it's testable without one.
What's happening
wait_for_download(crates/flowproof-adapters/src/web.rs:2929-2955) snapshots"what files already exist" as its baseline inside the function, at call time —
not at browser launch, and not at the click/step that actually triggers the
download. If the download completes and the browser renames the file off
.crdownloadin the gap between the triggering step returning and theWait until the download completes as <name>step actually invokingwait_for_download— realistic for small/fast exports, or just a slow stepdispatch — the file is already sitting in the baseline snapshot when the poll
starts. It's therefore never seen as "new," and the step spins to its full
timeout and reports a failure even though the download genuinely succeeded.
There is no unit or integration test for
wait_for_downloadat all — it needsa real browser, and isn't covered even in the gated e2e diff that introduced
it (#483).
If we don't fix it
Any flow with a fast export (the common case, e.g.
examples/fiori/purchase-info-records-report.flow.yaml'sExcel export) is flaky in exactly the direction this project cannot afford:
a real, successful download reported as a failure. On a slower CI runner this
may not reproduce; on a fast one or a small file it will, intermittently.
If we fix it
The wait step becomes reliable regardless of how fast the download completes
relative to step dispatch.
Suggested direction
Track already-claimed download files as persistent driver state (populated at
launch or at the point downloads are enabled), rather than re-diffing the
whole directory fresh on every
wait_for_downloadcall. That keeps the"exactly one new file" contract for the sequential-download case (#483's
stated goal) while closing the fast-download race.
Before closing
Needs a regression test for
wait_for_downloaditself — something thatproves a file present in the directory before the wait call, but written by
the download this step is waiting for, is still recognized. A real browser is
needed to exercise this end to end; at minimum, extract the "which files
count as new" logic so it's testable without one.