Aller au contenu principal

Crash-resume — tuer Pulse en plein vol

Intermédiaire ⏱ 10 min durabilité · offsets · production

Vous allez construire : de la confiance. Vous allez tuer un Pulse en marche de la façon la plus brutale, le redémarrer, et vérifier que votre pipeline reprend exactement où il s'était arrêté — parce que les offsets de flux par agent sont persistés, pas gardés en mémoire.

événements en cours → kill -9 → redémarrage → mêmes offsets, ni trou, ni doublon

Prérequis​

  • N'importe quelle application déployée (le hello du démarrage rapide est parfait).
  • Un Pulse local que vous avez le droit de tuer.

1 · Établissez une base qui coule​

pulse events publish --topic hello.in --value '{"severity":"error","msg":"before-crash-1"}'
pulse events publish --topic hello.in --value '{"severity":"error","msg":"before-crash-2"}'
pulse events tail --topic hello.triage.out

Deux événements passés, visibles en sortie. Laissez le tail tourner dans son propre terminal.

2 · Tuez-le — sans arrêt propre​

Trouvez le processus Pulse et tuez-le brutalement (kill -9), ou fermez simplement le terminal qui exécute pulse server start --dev. Le tail se déconnecte : le serveur est réellement mort en plein vol.

3 · Redémarrez​

pulse server start --dev

Même répertoire de données, mêmes apps : votre pipeline se redéploie depuis son état persisté — vous ne relancez pas pulse deploy.

4 · Prouvez la reprise​

pulse events publish --topic hello.in --value '{"severity":"error","msg":"after-crash"}'
pulse events tail --topic hello.triage.out

Le nouvel événement circule normalement. Maintenant relisez le topic depuis le début : les deux événements before-crash sont toujours là — les topics durables ont survécu — et ils n'ont pas été retraités au redémarrage : aucune sortie en double, parce que chaque agent a repris depuis son offset persisté par (agent, topic).

Ce qui vient de se passer​

Deux garanties distinctes ont travaillé ensemble :

  1. Les topics sont des logs durables — les événements écrits avant le crash sont toujours lisibles après.
  2. La consommation est checkpointée — la position de lecture de chaque agent est persistée, donc un redémarrage reprend exactement où il s'était arrêté : rien de sauté (pas de trou), rien de rejoué dans vos sinks (pas de double action).

C'est la fondation ennuyeuse et porteuse sous tout le reste du parcours Vers la production — et elle est active par défaut, pas un mode à activer.

Dépannage​

Après le redémarrage, mon app a disparu

Vous avez démarré le serveur avec un autre répertoire de données. Le mode dev persiste dans son répertoire par défaut — redémarrez avec le même que celui utilisé avant le kill.

Je revois les anciens événements dans mon tail

Relire un topic depuis le début est un choix de lecteur (c'est la durabilité qui fonctionne). La garantie porte sur les agents : vérifiez le topic de sortie du stage — chaque entrée d'avant-crash a produit exactement une sortie.

Ensuite​