Repository navigation
feat(oe-raflow): journal bloquant, exception documentée pour Decider::decide - #45
Merged
Merged
Conversation
…:decide Deuxième morceau du chantier « Recorder async » (docs/WEBUI.md §7, §15 étape 2b ; recoupe aussi l'item P0 J-2 de l'audit du 2026-09-25). - oe_raflow::Recorder devient async (#[async_trait]). - Flow::open (nouvelle demande) réordonné comme oe-ca-core : le journal s'écrit avant store.create_request. Si le journal échoue, aucune demande n'est créée. - Decider::decide (approve/reject RA) est une EXCEPTION DOCUMENTÉE, décidée avec l'utilisateur : l'écriture optimiste (update_request, CAS sur l'état Pending) reste avant le journal, parce qu'elle départage deux décisions concurrentes sur la même demande. Journaliser avant risquerait de consigner une décision qui perd la course et n'a jamais eu lieu. Conséquence assumée et testée : un échec du journal après decide() laisse la décision déjà appliquée en base, malgré l'erreur rendue à l'appelant. - oe-actions avait déjà la propagation de l'échec du journal (Error::Journal, commentaire « le journal d'abord » déjà présent) : seul le passage en async restait à corriger (.await ajouté à 14 sites), plus deux écritures délibérément best-effort (refus d'amorçage à un système verrouillé, échec de republication de CRL après une révocation déjà acquise) laissées telles quelles, désormais await-ées proprement. - ca-server, ra-console : mise à jour des implémentations de test (MemJournal, NullJournal) et de l'AuditRecorder de production. Reste : oe_tsa_core::Recorder et oe_timesource::Recorder (tsa-server), même démarche ; puis le câblage S3 réel de ca-server. Vérifications : cargo fmt --check, cargo clippy --workspace --all-targets (1.97 et 1.98.1), cargo test --workspace (avec OE_CASTORE_TEST_DSN), cargo audit. Contrôle par mutation : le réordonnancement de Flow::open échoue pour la bonne raison quand on revient à l'ordre précédent ; un test dédié prouve et documente le comportement de l'exception sur Decider::decide (décision appliquée malgré l'échec du journal).
This was referenced Sep 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Contexte
Deuxième morceau du chantier « Recorder async » (docs/WEBUI.md §7, §15 étape 2b ; recoupe aussi l'item P0 J-2 de l'audit du 2026-09-25,
docs/AUDIT_2026_09_25.md/TODO.md§0). Suite de #42 (oe-ca-core, mergée). Basedev.Contenu
oe_raflow::Recorderdevient async (#[async_trait]).Flow::open(nouvelle demande) réordonné commeoe-ca-core: le journal s'écrit avantstore.create_request. Si le journal échoue, aucune demande n'est créée.Decider::decide(approve/reject RA) est une exception documentée, décidée avec vous : l'écriture optimiste (update_request, CAS sur l'étatPending) reste avant le journal, parce qu'elle départage deux décisions concurrentes sur la même demande — journaliser avant risquerait de consigner une décision qui perd la course et n'a jamais eu lieu. Conséquence assumée et testée : un échec du journal aprèsdecide()laisse la décision déjà appliquée en base, malgré l'erreur rendue à l'appelant.oe-actionsavait déjà la propagation de l'échec du journal (Error::Journal, commentaire « le journal d'abord » déjà présent dans le code) : seul le passage en async restait à corriger (.awaitajouté à 14 sites), plus deux écritures délibérément best-effort (refus d'amorçage à un système verrouillé, échec de republication de CRL après une révocation déjà acquise) laissées telles quelles.ca-server,ra-console: mise à jour des implémentations de test (MemJournal,NullJournal) et de l'AuditRecorderde production.Reste :
oe_tsa_core::Recorderetoe_timesource::Recorder(tsa-server), même démarche ; puis le câblage S3 réel deca-server(2b-B).Vérifications
cargo fmt --checkcargo clippy --workspace --all-targets -- -D warnings(1.97 et 1.98.1)cargo test --workspace(avecOE_CASTORE_TEST_DSN) : vert, y compris 2 nouveaux tests (réordonnancement deFlow::open, et l'exception documentée surDecider::decide)cargo audit --ignore RUSTSEC-2023-0071: rien à signalerFlow::openéchoue pour la bonne raison quand on revient à l'ordre précédent