Eight red builds since 31 October. Three causes, only one of them still open.
| Build | Date | Cause | |
|---|---|---|---|
| #109 Card search | 4 Nov | large-canvas timing test: 505 ms CPU, limit 500 | test |
| #107 Silent demo videos | 4 Nov | GitHub had no macOS arm64 runner free (“job was not acquired”) | GitHub |
| Tooltip of a canvas's pause | 2 Nov | host app forwarding test – already fixed the same day | fixed |
| Strip of a view at the column's foot | 2 Nov | large-canvas timing test: 1067 ms | test |
| Box ticked in a plan folder | 2 Nov | large-canvas timing test | test |
| Navigation's waiting cards | 2 Nov | large-canvas timing test | test |
| Every wait between cards | 2 Nov | large-canvas timing test: 835 ms | test |
| Watch for new code | 31 Oct | large-canvas timing test: 706 ms | test |
#108 was not a failure: it was cancelled because #109 was pushed right after it.
The test checks that thirty cards landing one after another don't freeze the server – a regression fixed on 31 October, when every single write rebuilt the whole canvas view. It demanded “under 500 ms of CPU”. On a laptop the run takes about 100 ms; GitHub's runner computes the same run four to eight times slower, so it landed right around the limit and failed whenever the runner was a bit slower.
Now the test measures the run against a rebuild of the canvas view on the same machine, and counts only the thread that runs the server's code. A slower machine makes both slower, so the ratio stays put:
So the test still catches the bug it was written for, with room on both sides, regardless of how fast the machine is. The neighbouring test for sharing demo pages got the same treatment (about 2 rebuilds, limit 10).