mirror of
https://github.com/4gray/iptvnator.git
synced 2026-10-09 01:16:15 -08:00
The packaging verifier bounded `iptvnator_mpv_helper --runtime-probe` with RUNTIME_PROBE_TIMEOUT_MS (3s) — a constant it shares with the application's own startup capability gate. Three seconds is a tight budget for a helper that dlopens libmpv plus EGL/GL/GBM, and the Flatpak profile is closest to that edge because the helper runs inside the sandbox against its bundled closure: on #1277 the job failed three consecutive reruns and passed on the fourth with no code change, while the concurrent master job passed. Give the verifier its own budget rather than raising the shared one. The app's probe is a blocking spawnSync on the Electron main process, so a hung helper must not stall window creation, and a timeout there degrades gracefully to the native-view fallback. Nothing waits on the packaging probe but the CI job, which already has its own 120-minute bound, while a premature kill reports a healthy package as broken. - PACKAGE_VERIFICATION_PROBE_TIMEOUT_MS (15s) and PACKAGE_VERIFICATION_PROBE_MAX_ATTEMPTS (2) join the frozen probe contract; RUNTIME_PROBE_TIMEOUT_MS stays at 3s for the application gate. - runBoundedRuntimeProbe() retries only on ETIMEDOUT, repeating the identical bounded launch (same command, args, env, maxBuffer, killSignal) and announcing the retry on stderr so a degrading trend stays visible. Fail-closed behaviour is unchanged. A hard timeout is the one probe outcome that says nothing about the payload; spawn errors (a missing helper, a wrapper launched instead of the real ELF), termination by signal, nonzero exits and malformed or wrong-protocol lines all still fail on the first attempt, and a helper that keeps hanging still fails once both attempts are spent. The four new/extended verifier tests cover retry-then-success (asserting the second launch is identical to the first), exhausted timeouts still rejecting, four non-timeout verdicts each probing exactly once, and the attempt bound itself. Setting MAX_ATTEMPTS to 1 fails four of them. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
30 lines
1.5 KiB
JavaScript
30 lines
1.5 KiB
JavaScript
// Shared bounds for `iptvnator_mpv_helper --runtime-probe`.
|
|
//
|
|
// The two timeouts differ on purpose, because the two callers pay different
|
|
// costs for waiting:
|
|
//
|
|
// - RUNTIME_PROBE_TIMEOUT_MS bounds the application's own startup capability
|
|
// decision, a blocking spawnSync on the Electron main process. A hung helper
|
|
// must not stall window creation, and a timeout there degrades gracefully to
|
|
// the native-view fallback, so this budget stays short.
|
|
// - PACKAGE_VERIFICATION_PROBE_TIMEOUT_MS bounds the one-shot packaging check
|
|
// in tools/packaging/verify-linux-frame-copy-runtime.mjs. Nothing waits on it
|
|
// but CI, which already has its own job-level bound, while a premature
|
|
// timeout produces a false "broken payload" verdict on a healthy package.
|
|
// Cold sandboxes — Flatpak most of all — spend seconds just loading libmpv
|
|
// plus the EGL/GL/GBM stack, so this budget is generous.
|
|
//
|
|
// A hard timeout is also the one probe outcome that says nothing about the
|
|
// payload, so the packaging verifier repeats it up to
|
|
// PACKAGE_VERIFICATION_PROBE_MAX_ATTEMPTS times. Every other outcome — spawn
|
|
// error, signal, nonzero exit, malformed protocol line — remains fail-closed on
|
|
// the first attempt, and a helper that genuinely hangs still fails the check.
|
|
const RUNTIME_PROBE_CONTRACT = Object.freeze({
|
|
RUNTIME_PROBE_MAX_BUFFER_BYTES: 16 * 1024 * 1024,
|
|
RUNTIME_PROBE_TIMEOUT_MS: 3000,
|
|
PACKAGE_VERIFICATION_PROBE_TIMEOUT_MS: 15000,
|
|
PACKAGE_VERIFICATION_PROBE_MAX_ATTEMPTS: 2,
|
|
});
|
|
|
|
module.exports = RUNTIME_PROBE_CONTRACT;
|