Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

clickhouse-containers.mjs: attachDockerNetworkWithRollback races container cold-start instead of confirmed readiness

Ouverte
  • Quelque chose ne va pas ?
#623 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
68/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Calme
Stack technique
docker, javascript
Domaine
infrastructure, testing

Piste de recherche

Commencez dans tests/spike/clickhouse-client/clickhouse-containers.mjs, au niveau de attachDockerNetworkWithRollback (lignes 277-306) et de startRow (lignes 419-422), puis comparez son comportement de probePing avec waitForReady. Consultez spike-server.mjs:167-173 pour l’ordre de démarrage séquentiel et reproduisez le cas de démarrage lent. C’est terminé lorsque l’invariant de readiness documenté est vrai au niveau du site d’appel et que le réseau du conteneur n’est pas rétabli silencieusement pendant le démarrage à froid.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

inbox

attachDockerNetworkWithRollback's docstring in tests/spike/clickhouse-client/clickhouse-containers.mjs:292-297 claims the port was "confirmed reachable at container-boot time by the caller before this runs" — but startRow calls it at line 419 before waitForReady at line 422. Nothing confirms reachability before the attach runs.

The function's 4×1s probePing (lines 277-289, 306) therefore races ClickHouse's own cold start rather than checking an already-confirmed-live port. Found live and reproducibly (3/3 runs) during #585 Phase 0 WebKit-browser-matrix flake research: current-altinity-stable is consistently the row that loses this race and gets silently rolled back to default-bridge-only networking, because it's booted last (sequential boot order in spike-server.mjs:167-173) under maximum accumulated Docker load — so its cold start is slowest and most likely to still be starting when the probe fires.

This is comment/invariant drift (the docstring asserts a precondition the call site doesn't actually provide) that makes container network topology depend on relative boot speed rather than a real readiness check. Low urgency — this harness is dev/spike-only, not production — but worth fixing before the harness is relied on again for a rerun of the #585 browser matrix, since it's a plausible contributor to that matrix's one flaky cell (see #585 ship-log / ADR-0005 evidence discussion).

Suggested fix: either call attachDockerNetworkWithRollback only after waitForReady resolves (matching the docstring's own claimed precondition), or have the docstring/precondition match reality (loosen probePing's retry budget, or make it wait for the same readiness signal waitForReady uses).

Found by: automated root-cause research launched from a /ship-adjacent session, 2026-08-06.

Langage dominant
TypeScript
Étoiles
8
Forks
2
Merge moyen
1 h 17 min
PR mergées (30 j)
3

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de Altinity/altinity-sql-browser

Toutes les issues de Altinity/altinity-sql-browser

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.