Reconnexion/ng-eventually
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: deux exécutions peuvent maintenant se chevaucher

Browse Source 
La feuille disait le contraire, et c'est moi qui l'ai écrite hier : « deux
exécutions ne doivent jamais se chevaucher », « c'est désormais tenu par un
verrou », « une suite d'un dépôt consommateur entre en collision ». Les trois
sont fausses depuis l'extraction.

Chaque exécution a son propre répertoire de profil et tue le navigateur qui le
détient en finissant. Les exécutions concurrentes — y compris celle d'une
application consommatrice, depuis son propre dépôt — sont indépendantes par
construction.

Et la leçon de forme est consignée, parce qu'elle se généralise : le verrou ne
traitait qu'un symptôme, supprimer le partage a supprimé le besoin. Quand deux
exécutions se disputent une chose, la rendre propre à chacune plutôt que de
sérialiser l'accès.
This commit is contained in:
Sylvain Duchesne
2026-08-16 14:17:38 +02:00
parent 0607843b81
commit 9e7aeef269
2 changed files with 5 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.project/concepts/e2e-harness/_debt.md
-11
View File
@@ -1,11 +0,0 @@
# Doc-debt — e2e-harness
> Presence of a block = doc to update. Processed → delete the block; no blocks left → delete this file.
> One block = one "big change": `why` + `files` + `verify` (leaves to review).
## Raw markers (consolidate into blocks, then delete)
- TOUCHED packages/polyfill/e2e/harness-page.ts @2026-08-16 (session f93872b5-293a-4916-a353-181409a96d42)
- TOUCHED packages/polyfill/e2e/run.ts @2026-08-16 (session f93872b5-293a-4916-a353-181409a96d42)
- TOUCHED packages/polyfill/e2e/reactivity-doc-subscribe.ts @2026-08-16 (session f93872b5-293a-4916-a353-181409a96d42)
- TOUCHED packages/polyfill/e2e/repro-fresh-wallet.ts @2026-08-16 (session f93872b5-293a-4916-a353-181409a96d42)
- TOUCHED packages/polyfill/e2e/notebook.ts @2026-08-16 (session f93872b5-293a-4916-a353-181409a96d42)
.project/concepts/e2e-harness/knowledge_what-each-suite-judges.md
+5 -7
View File
@@ -15,17 +15,15 @@ A unit suite cannot replace any of them, and none of them replaces the unit suit
## What a batch costs, and why
Every `batch` mints its own physical user by driving the wallet application's real interface, then discards the previous one. That is deliberate — identities must not leak between runs — and it puts a floor under every run that no test filter can remove.
Every run mints its own physical user by driving the wallet application's real interface, then discards the previous one. That is deliberate — identities must not leak between runs — and it puts a floor under every run that no test filter can remove.
Consequences worth knowing before optimizing anything: the setup runs before any `journey`, so a filter saves journey time only; and the wallet profile is a single directory shared by every suite.
Consequence worth knowing before optimizing anything: the setup runs before any `journey`, so filtering journeys saves journey time only — the floor stays.
## Two runs must never overlap
## Two runs may overlap — and that was not free
Because the profile is shared and each `batch` discards what it finds, a second run started while a first is alive destroys the first — which then fails in a way that reads as a product defect. Several measurements were lost to this before it was made structural.
They once could not: the profile was a single shared directory, and a run starting while another was alive destroyed it, which then failed in a way that read as a product defect. Several measurements were lost to it.
It is now enforced by a lock rather than by discipline, and a browser left behind by a killed run is reclaimed. If you ever find yourself reasoning about "was another run going?", check the lock rather than your memory.
That lock guards **this repository only**. A suite belonging to a consuming application, run from its own checkout against the same broker and the same wallet, collides exactly as two of ours would — observed. Until the shared machinery lives in a package both sides use, that collision is invisible to both.
Now each run gets its own profile directory and kills the browser holding it when it ends, so concurrent runs — including a consuming application's suite, from its own checkout — are independent by construction. A lock once guarded the shared directory; it treated the symptom, and removing the sharing removed the need. Prefer that shape whenever two runs contend: make the contended thing per-run rather than serialising access to it.
## A bound must be larger than the sum of what it encloses