Timers 1.5.1: a failed capture-tool build must not park the listener forever

Found live on AB: the build failed (its CLT is broken), the compiled
binary was then copied in by hand — and the listener never noticed. It
had seen 'build in flight' and stopped scheduling retries, waiting for
ensureCaptureBinary's onReady, which only fires on SUCCESS. The tile said
'Capture tool building…' indefinitely with a working binary on disk; only
a module remount recovered it.

onReady stays as the fast path; the 30 s retry now stays armed in every
not-ready state, so a failed build keeps re-checking and a binary that
arrives from outside (scp'd to a machine that can't compile) is picked up
within half a minute.

Reproduced the exact shape in a swiftc-less environment: build fails,
binary copied in at 3 s, retry at 30 s spawns it (the capture's own
unknown-device answer proves the real binary ran) — previously a
permanent deadlock.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

This commit is contained in:

Waters Church

2026-09-27 10:55:44 -04:00

co-authored by

Claude Fable 5

parent 4c6a2b8f76

commit 62c34fe80c

2 changed files with 8 additions and 4 deletions

									
										modules/propresenter-timers/module.json
									
		+1
		-1
	
												View File
												
				@@ -1,7 +1,7 @@

				{

				  "id": "propresenter-timers",

				  "name": "Timers",

				  "version": "1.5.0",

				  "version": "1.5.1",

				  "proddash": ">=1.4.0",

				  "description": "Timers, Clocks, and LTC From configured Modules",

				  "provides": [