From 00c882a8d27a6d1bc7415b9a89f801c9c64a974e Mon Sep 17 00:00:00 2001 From: satoshi Date: Mon, 27 Apr 2026 21:53:53 +0300 Subject: [PATCH] Lower fallback grace default from 30s to 3s ckpool patch 0004 now bounds generator_submitblock's wait for a live primary to ~3s rather than spinning indefinitely, and calls submit before writing the pending-block hex to disk so the happy path adds zero latency. The right default is small: a fallback should kick in while the work is still relevant for the current chain tip. Range widened to [1, 600] so impatient operators can crank further down. Description updated to reflect the new architecture. --- scripts/procedures/getConfig.ts | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/scripts/procedures/getConfig.ts b/scripts/procedures/getConfig.ts index 97300b6..6002878 100644 --- a/scripts/procedures/getConfig.ts +++ b/scripts/procedures/getConfig.ts @@ -230,12 +230,12 @@ export const getConfig: T.ExpectedExports.getConfig = compat.getConfig({ "type": "number", "name": "Grace period (seconds)", "description": - "How long a block waits before kamado-api considers ckpool's submission attempt failed and broadcasts via fallback. 30s gives ckpool's own retry loop room to succeed against the primary.", + "How long a block waits before kamado-api considers ckpool's submission attempt failed and broadcasts via fallback. The patched ckpool returns from submit within ~3s rather than spinning indefinitely on a dead primary, so 3s is the right default — fast enough that fallback work happens while the block is still novel, long enough that a slow round-trip on a healthy primary doesn't trigger a spurious fallback.", "nullable": false, - "range": "[10,600]", + "range": "[1,600]", "integral": true, "units": "seconds", - "default": 30, + "default": 3, }, "backup-rpcs": { "type": "list",