You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maka.apache.org by "me2seeks (via GitHub)" <gi...@apache.org> on 2026/08/22 10:19:57 UTC
[PR] fix(runtime-host): let operators raise the election deadline and clarify timeout copy [maka]
me2seeks opened a new pull request, #3480:
URL: https://github.com/apache/maka/pull/3480
Closes #3474
## Problem
On a large workspace (~788 MB `runtime.sqlite`), the first Runtime Host start after an upgrade emitted `runtime_host_ready` after ~75s — 30s after the client's fixed 45s election window had already elapsed. The user sees:
```
Error: Runtime Host stopped responding during startup
```
which is misleading: the host was alive and making progress the whole time. The candidates spawned during the election keep starting detached, so they eventually win and hold the root while every later attempt starts from a cold election again.
## Change
- `MAKA_RUNTIME_HOST_ELECTION_DEADLINE_MS` now overrides the default election deadline at its single resolution point in `connectOrSpawnRuntimeHostWithDependencies`, so CLI, desktop, and owned launches all honor it. The window stays bounded (1–120000 ms). Invalid values fail closed with a \`RangeError\` naming the variable — a silently ignored typo would leave the operator believing they widened the window when they did not.
- The two deadline-elapsed failure copies (`startup_timeout`, `host_unresponsive`) no longer claim things neither reason can know ('stopped responding'). They describe what was observed, name slow first starts on large workspaces as the likely cause, and point at the override.
- No candidate lifecycle change: ephemeral candidates already self-terminate via their initial connection deadline once startup settles; the lingering processes in #3474 were startup work starving the timer, not missing exit logic.
## Testing
- New `election-deadline-env.test.ts`: blank/unset handling, valid parsing, fail-closed on invalid values, and an ordering test proving an invalid override fails before storage is touched.
- `startup-error.test.ts` updated for the new copy plus a knob-mention assertion.
- Desktop manager assertions updated to the new copy.
- `packages/runtime-host`: full suite 1067/1067 green; desktop manager suite 22/22; `tsc --noEmit` and biome clean.
Generated-by: Maka
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(runtime-host): let operators raise the election deadline and clarify timeout copy [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han merged PR #3480:
URL: https://github.com/apache/maka/pull/3480
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] fix(runtime-host): let operators raise the election deadline and clarify timeout copy [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han commented on code in PR #3480:
URL: https://github.com/apache/maka/pull/3480#discussion_r3835884811
##########
packages/runtime-host/src/client/connect-or-spawn.ts:
##########
@@ -173,7 +196,12 @@ export async function connectOrSpawnRuntimeHostWithDependencies(
input: ConnectOrSpawnRuntimeHostInput,
dependencies: ConnectOrSpawnRuntimeHostDependencies,
): Promise<ConnectOrSpawnRuntimeHostResult> {
- const deadlineMs = input.electionDeadlineMs ?? DEFAULT_ELECTION_DEADLINE_MS;
+ const deadlineMs =
+ input.electionDeadlineMs ??
+ electionDeadlineMsFromEnvironment(
Review Comment:
[P3] On the owned-launch path an invalid value loses the variable name and surfaces as `host_unresponsive`.
`electionDeadlineMsFromEnvironment()` throws a `RangeError` naming the variable, which is exactly right for direct `connectOrSpawnRuntimeHost`. But `connectOwnedRuntimeHostWithDependencies()` wraps the call in a broad catch that converts anything into `{ kind: 'failed', reason: 'host_unresponsive' }`. So `MAKA_RUNTIME_HOST_ELECTION_DEADLINE_MS=abc` reaches the user as `Runtime Host did not start: host_unresponsive` — they're told the host is unresponsive when in fact they made a typo, and the message gives them nothing to act on.
This is the same shape as the finding above: the mechanism is fine, the diagnosis points the wrong way. Config errors specifically are worth letting through that catch (or resolving before it, as a typed configuration failure), since they're the one class the user can fix immediately once they know the variable name. Worth a test on both the owned and hosted paths.
##########
packages/runtime-host/src/client/connect-or-spawn.ts:
##########
@@ -56,13 +57,35 @@ export interface ConnectOrSpawnRuntimeHostInput {
interface ConnectOrSpawnRuntimeHostDependencies {
launchCandidate: CandidateLauncher;
random(): number;
+ /** Defaults to `process.env`; injected so tests never mutate the real environment. */
+ env?: NodeJS.ProcessEnv;
}
const defaultDependencies: ConnectOrSpawnRuntimeHostDependencies = {
launchCandidate: launchDetachedRuntimeHostCandidate,
random: Math.random,
};
+/**
+ * Resolves the operator override for the client election deadline. Large
+ * workspaces can legitimately take longer than the default window on their
+ * first start after an upgrade, so the deadline must be raisable without a
+ * code change. Invalid values fail closed: a silently ignored typo would leave
+ * the operator believing they widened the window when they did not.
+ */
+export function electionDeadlineMsFromEnvironment(
+ rawValue: string | undefined,
+): number | undefined {
+ if (rawValue === undefined || rawValue.trim() === '') return undefined;
+ const parsed = Number(rawValue);
+ if (!Number.isSafeInteger(parsed) || parsed <= 0 || parsed > 120_000) {
+ throw new RangeError(
+ `${ELECTION_DEADLINE_MS_ENV_VAR} must be an integer between 1 and 120000 milliseconds`,
Review Comment:
[P3] The error text points every startup failure at this variable, including the class it can't fix.
There's a second failure shape this knob doesn't address. From a real CI run on #3454, which now emits election diagnostics:
```json
{"deadlineMs":45000,"elapsedMs":45174,"candidateLaunches":69,
"observations":{"notRegistered":73,"connectFailed":0,"handshakeFailed":0,
"connected":1,"readyWaitFailed":1}}
```
69 candidate launches in 45 seconds. Zero connect failures, zero handshake failures — it connected once, then ready-wait failed, and candidates kept being launched roughly every 0.65s until the deadline. It missed by 174ms, so raising the deadline would have made *that particular run* pass, but the run isn't slow — it isn't converging. At 90s it launches ~138 candidates instead of ~69 and passing becomes a matter of luck.
That's different from #3474's genuinely-slow start, where waiting longer is exactly right. The problem is that both produce the same message, so an operator hitting the retry-storm shape is told to raise the timeout, raises it, fails again, and raises it further.
Not blocking, and possibly not yours to fix here — but worth asking: with `candidateLaunches` high and `connectFailed`/`handshakeFailed` at zero, should the message distinguish "this start is slow, wait longer" from "candidates aren't converging, the timeout isn't your problem"? You have the #3474 case in hand and probably know which shape operators hit more often.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org