Sasedev/khadhroony-solana-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.3.7-pre.010

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-09-02 18:56:09 +02:00
parent 97f84e5c58
commit 313d2a1ea6
20 changed files with 533 additions and 40 deletions
Download Patch File Download Diff File Expand all files Collapse all files

11
docs/plans/028-V0_3_7_BACKFILL_DESK_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/028-V0_3_7_BACKFILL_DESK_PLAN.md -->
<!-- version: 9 -->
<!-- version: 10 -->
# Plan v0.3.7 — Backfill Desk
@@ -123,7 +123,7 @@ Commandes prévues :
backfill_options() -> BackfillDeskOptionsDto
backfill_status() -> BackfillRunStatusDto
backfill_start(request) -> BackfillRunStatusDto
backfill_cancel() -> BackfillCancelResponseDto
backfill_cancel(job_id) -> BackfillCancelResponseDto
backfill_resume() -> BackfillResumeResponseDto
backfill_reset() -> BackfillRunStatusDto
```
@@ -182,8 +182,9 @@ Règles :
- start atomique : refus si un run est `starting/running/cancelling` ;
- le handle est installé avant spawn afin que Cancel ne perde pas la course au démarrage ;
- Cancel cible le `job_id` backend affiché par le monitoring afin qu'une requête IPC retardée ne puisse jamais annuler un run ultérieur ;
- Cancel répété est idempotent au niveau UX, mais le retour expose si la demande a été acceptée ;
- un terminal publié gagne sur un Cancel tardif ;
- un terminal publié gagne sur un Cancel tardif ; un Cancel visant l'ancien JobId après admission d'un nouveau run est rejeté comme mismatch ;
- la source latest-value est conservée jusqu'à projection du terminal ;
- reset/new campaign n'est autorisé qu'en absence de run actif ;
- fermeture de l'application déclenche une demande d'annulation coopérative best-effort puis laisse la destruction du process terminer les ressources ; aucune promesse de drain crash-safe n'est faite ;
@@ -275,7 +276,9 @@ Le backend émet `ksp-backfill-status` à partir de `JobSnapshotSource::wait_for
### pre.010 — Cancel et races terminales
Cancel, état cancelling, idempotence UX, concurrence Start/Cancel/terminal, sémantique de drain Store et fermeture app.
Ajouter `backfill_cancel(job_id)` avec `BackfillCancelResponseDto { accepted, job_id, state }`. Le JobId est celui généré par le backend et projeté par le monitoring ; il cible le slot actif pour empêcher un Cancel IPC retardé d'atteindre un run suivant. Le premier Cancel pré-terminal est accepté, les répétitions sont idempotentes et renvoient `accepted=false`, un terminal gagne sur un Cancel tardif et un JobId périmé est rejeté sans toucher au run courant.
Le frontend expose **Annuler** uniquement pour un status actif, trace seulement JobId/état/acceptation et se resynchronise par `backfill_status`. L'état `cancelling` reste l'intention coopérative : le runtime arrête les nouvelles admissions mais draine le travail déjà soumis au Store. À la fermeture de la fenêtre principale, le one-shot shutdown bloque d'abord les nouveaux Starts, demande ensuite best-effort l'annulation du run actif, puis poursuit le shutdown Store/process sans promettre un drain crash-safe. Resume reste hors tranche.
### pre.011 — checkpoint/frontier et Resume