syonad/two
2
0
Fork 0
Code Issues 17 Pull requests 1 Projects Releases 4 Packages Wiki Activity Actions

ajout d'un etat error #37

New issue
Closed
opened 2026-08-13 12:38:11 +00:00 by nicolas.boufideline · 3 comments
nicolas.boufideline commented 2026-08-13 12:38:11 +00:00
Owner
Copy link

quand les vms sont creer elle reste en creating meme quand il y a une erreur, il faudrait ajouter un status error.

quand les vms sont creer elle reste en creating meme quand il y a une erreur, il faudrait ajouter un status error.
nicolas.boufideline commented 2026-08-13 12:45:31 +00:00
Author
Owner
Copy link

il faudrait ajouter un check sur les delete pour vérifier que la ressource est en etat error ou dans un running, (peut-être qu'un changement des états created vers running serais bien)

il faudrait ajouter un check sur les delete pour vérifier que la ressource est en etat error ou dans un running, (peut-être qu'un changement des états created vers running serais bien)
nicolas.boufideline commented 2026-08-15 20:53:05 +00:00
Author
Owner
Copy link

on avance a notre rythme

on avance a notre rythme
nicolas.boufideline commented 2026-08-25 12:39:19 +00:00
Author
Owner
Copy link

Livré, validé sur lab1 le 2026-08-14.

Machine à états — creating → running → deleting → deleted, plus error atteignable depuis creating et deleting, et d'où un deleting de reprise est possible. Mêmes états pour VPC, subnet et VM : le vocabulaire VM starting/started/stopping/stopped disparaît.

Décisions

  • Pas de clé error en base : la cause de l'échec reste dans les logs slog, state=error seul.
  • Le passage à error est positionné uniquement par Dispatcher.Dispatch via cmd.Key(), jamais ailleurs — d'où l'ajout de Key() à l'interface Command.
  • Suppression autorisée depuis running ou error seulement, sinon 409. Depuis error elle est best-effort : les ressources système peuvent être partiellement créées, cohérent avec la décision « pas de rollback ».
  • Tout passe par state.Get / state.Set : Set refuse une valeur hors enum, Get refuse d'en retourner une non reconnue.

Une étape du plan s'est révélée impossible telle quelle — le gating du delete et le renommage created/started → running devaient être deux étapes ; state.Get refusant toute valeur hors enum, un gating livré seul aurait rendu indélétable toute ressource existante. Les deux forment un seul changement atomique. Leçon générale : chaque étape d'un plan doit laisser le dépôt cohérent.

Migration au démarrage, idempotente, jouée après InitDB et avant le serveur HTTP : created/started → running, stopped → deleted, et tout état transitoire → error (la queue worker étant en mémoire, une ressource restée transitoire est forcément orpheline). Une valeur ni ancienne ni nouvelle part aussi en error avec reason=unknown state, plutôt que de bloquer l'agent au démarrage. Chaque transition est loguée.

Bug corrigé au passage — deleteSubnet renvoyait 404 pour toute erreur de Prepare, masquant un refus d'état en 404. Aligné sur la convention vpc/vm : 404 si absent, 409 sinon.

Point d'attention — cette feature ne relance pas les ressources en error : c'est au caller de supprimer puis recréer.

Livré, validé sur lab1 le 2026-08-14. **Machine à états** — `creating → running → deleting → deleted`, plus `error` atteignable depuis `creating` et `deleting`, et d'où un `deleting` de reprise est possible. Mêmes états pour VPC, subnet et VM : le vocabulaire VM `starting`/`started`/`stopping`/`stopped` disparaît. **Décisions** - **Pas de clé `error` en base** : la cause de l'échec reste dans les logs `slog`, `state=error` seul. - Le passage à `error` est positionné **uniquement** par `Dispatcher.Dispatch` via `cmd.Key()`, jamais ailleurs — d'où l'ajout de `Key()` à l'interface `Command`. - Suppression autorisée depuis `running` ou `error` seulement, sinon 409. Depuis `error` elle est **best-effort** : les ressources système peuvent être partiellement créées, cohérent avec la décision « pas de rollback ». - Tout passe par `state.Get` / `state.Set` : `Set` refuse une valeur hors enum, `Get` refuse d'en retourner une non reconnue. **Une étape du plan s'est révélée impossible telle quelle** — le gating du delete et le renommage `created`/`started` → `running` devaient être deux étapes ; `state.Get` refusant toute valeur hors enum, un gating livré seul aurait rendu **indélétable toute ressource existante**. Les deux forment un seul changement atomique. Leçon générale : chaque étape d'un plan doit laisser le dépôt cohérent. **Migration au démarrage**, idempotente, jouée après `InitDB` et avant le serveur HTTP : `created`/`started` → `running`, `stopped` → `deleted`, et **tout état transitoire → `error`** (la queue worker étant en mémoire, une ressource restée transitoire est forcément orpheline). Une valeur ni ancienne ni nouvelle part aussi en `error` avec `reason=unknown state`, plutôt que de bloquer l'agent au démarrage. Chaque transition est loguée. **Bug corrigé au passage** — `deleteSubnet` renvoyait 404 pour *toute* erreur de `Prepare`, masquant un refus d'état en 404. Aligné sur la convention vpc/vm : 404 si absent, 409 sinon. **Point d'attention** — cette feature **ne relance pas** les ressources en `error` : c'est au caller de supprimer puis recréer.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
feature-50
feature-51
pages
release-0.1.0
dashboard
intel
0.2.0rc003
0.2.0rc002
0.2.0rc001
0.1.0
Labels
Clear labels   
bug fix
Fix a bug present in an error

  
feature implementation
Implementation of a feature in the compile

  
new feature
New feature for the project

No labels
bug fix
feature implementation
new feature
Milestone
Clear milestone
No items
No milestone
0.1.0
Projects
Clear projects
No items
No project
Feature Gestion
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
syonad/two#37
No description provided.