jb/harness-tools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: confirm asynchronous close race and test-first correction

Browse Source
This commit is contained in:
jb
2026-09-21 13:32:57 -04:00
parent f2e42f5faf
commit 6a725c1f47
1 changed files with 3 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/plans/fast-browser-performance.md
+3 -1
View File
@@ -120,4 +120,6 @@ After safe integration, make one record-only closure commit, prove reachability,
- A correction smoke passed; historical pre-correction transient popup-close failure is preserved at `/tmp/performance-smoke-final.json`, not attributed to concurrent editing. Stable paired measurements must include all failures.
- First stable 20-pair result `/tmp/fast-browser-performance-20-pairs.json`: exit 1; baseline 19/20 and optimized 18/20 warm flows passed, all six cold attempts passed, counters/cleanup complete. Failures are popup-close verification (optimized samples 10/13, baseline sample 20). 60-control median observation 79 to 30ms; 10-control 16 to 7ms, but aggregate medians 445 to 551ms. These are diagnostic results, not acceptance.
- Additional bounded assignments: browser-hotpath read-only diagnosis (8 minutes), performance-benchmark safe per-operation timing in its existing four paths (15 minutes). Before state acd57ae, product paths clean; only parent performance doc untracked. No scope/API/security expansion: this is required existing benchmark verification.
- Next safe action: inspect diagnostic delivery, correct confirmed contract-preserving hot-path issues, then rerun the original paired command. Preserve every failed result.
- Browser diagnosis confirmed one-shot close verification races asynchronous Target.closeTarget completion; removing the duplicate inventory makes the pre-existing race more visible. Proposed correction repeats only inventory reads within the existing action-verification budget, never the close mutation. This restores intended verified-close behavior without API/security changes.
- Browser-hotpath test-first assignment: 8 minutes, only its existing Python test path, at f2e42f5 with benchmark-owned TS files dirty; product Python remains stable during diagnostic measurement. Add deterministic delayed-disappearance and permanent-presence close cases, prove the first fails before the fix, then return. Before patch `/tmp/pi-present/performance-before-close-tests.patch`.
- Next safe action: complete diagnostic measurement, apply the bounded close verification fix through the same owner, then rerun the original paired command. Preserve every failed result.