3 Commits

Include renames

Author	SHA1	Message	Date
jschoubben	1dc5d8cb3d	Run a watch's handler beside the runtime, and give a refused watch up loudly (issue 774) ... The provisioner's watches of gitea.bound, mesh-vault.bound and postgres.bound failed every minute for an hour on the control-node ("the current values ... did not arrive in 10s") and 1257 changes were refused as "names no watch of this bundle". Both sides were at fault. The SDK answered a change only once its handler returned, so a slow handler (Rejudge waits on the lock its composition holds) counted against the runtime's 10 s bound on the current values; and when the runtime gave up, the SDK forgot the id at once. The runtime (mesh-tools node-tools internal/bus/state.go StateWatch) stops its watcher on that bound but still drains and delivers the values already buffered, to an id nobody holds. Quick fix: a longer runtime bound. Thorough fix here: each state and provision watch has a follower that takes a change in order and answers at once, its handler on its own goroutine; Watch still returns only once the current values were handled, and a handler's error is said on standard error. A watch the runtime refuses is said given up and kept by id, so a change still handed to it is refused saying so. KeptState.Follow asks again with backoff until taken, the loop four modules wrote for themselves. A log watch keeps its answer after the handler: that is its back-pressure.	2026-10-30 18:15:51 +01:00
fix-sdk-pas	0db956dd83	Skip a bad assignment, honour the plan's credential form, delete only what was read, redact every credential form (issue 825)	2026-10-16 19:28:25 +02:00
mesh-tools	1bc5719b8b	Feature 57 (config and provisioning): release mesh-sdk, the reviewed release branch on top of main	2026-10-16 08:24:11 +00:00