run-error-handling: job d'exécution sérialisé complet + erreur GPU affichée

- ROOT CAUSE : expire_on_commit vidait le __dict__ de l'instance Job après
  commit() → execute renvoyait {} → frontend poll GET /api/jobs/undefined
  en boucle (422) + faux succès (le job.error 'Location GPU…' était perdu)
- Backend : session.refresh(job) avant les 3 return de execute_pipeline —
  prouvé en réel : execute → 200 {id, status:error, error FR} (avant : {})
- Frontend : onRun n'affiche plus de succès sur job invalide ou déjà error —
  message job.error immédiat + failRun, pas de polling ; pollJob arrête le
  polling sur erreur 4xx permanente (hors 429)
- Test de régression : execute gpu (launch_instance mocké dummy) retourne
  id + status error — 96 passed (7 pré-existants /api/blocks*)
- Smoke navigateur réel (backend gpu, rent refusé) : console affiche
  'Exécution en erreur : Location GPU…', 0 undefined dans les logs

Author: Ouaziz-chedli

backend/mlblock/server/routes.py

@@ -456,6 +456,7 @@ def execute_pipeline(
             job.completed_at = datetime.now(timezone.utc)
             session.add(job)
             session.commit()
+            session.refresh(job)  # expire_on_commit vide le __dict__ — sinon la réponse est {}
             return job
         job.status = "dispatched"
         session.add(job)
@@ -469,6 +470,7 @@ def execute_pipeline(
     instance_id = job.vast_instance_id
 
     if _is_mock_vast():
+        session.refresh(job)  # expire_on_commit vide le __dict__ — sinon la réponse est {}
         return job
 
     gpu_timeout = int(os.environ.get("MLBLOCK_GPU_TIMEOUT", "1800"))  # 30 min par défaut
@@ -489,6 +491,7 @@ def _timeout_cleanup():
 
     threading.Timer(gpu_timeout, _timeout_cleanup).start()
 
+    session.refresh(job)  # expire_on_commit vide le __dict__ — sinon la réponse est {}
     return job
 
 

backend/mlblock/tests/test_server.py

@@ -542,3 +542,29 @@ def test_generated_code_instance_auth_and_self_destroy():
     main_body = code.split("def main():")[1]
     assert "finally:" in main_body
     assert "_self_destroy()" in main_body
+
+
+def test_execute_gpu_rent_failure_returns_full_job(client: TestClient, monkeypatch):
+    """Régression expire_on_commit : le rent GPU échoué retourne un job
+    sérialisé COMPLET (id + status error), pas un objet vide {}."""
+    class FakeVast:
+        def __init__(self, api_key): pass
+        def launch_instance(self, *a, **kw):
+            return {"id": "dummy-instance-id", "api_key": ""}
+        def start_instance(self, *a, **kw): pass
+        def destroy_instance(self, *a, **kw): pass
+
+    monkeypatch.setenv("MLBLOCK_RUN_MODE", "gpu")
+    monkeypatch.setenv("VAST_API_KEY", "real-key-for-test")
+    monkeypatch.setenv("MLBLOCK_GPU_TIMEOUT", "1")
+    monkeypatch.setattr("mlblock.server.routes.VastAI", FakeVast)
+
+    created = client.post(
+        "/api/pipelines", json={"name": "gpu-fail", "nodes": [], "edges": []}
+    ).json()
+    resp = client.post(f"/api/pipelines/{created['id']}/execute")
+    assert resp.status_code == 200
+    job = resp.json()
+    assert job.get("id"), f"job.id manquant dans la réponse : {job}"
+    assert job["status"] == "error"
+    assert "Location GPU" in job["error"]

frontend/src/hooks/useBlockRunner.ts

@@ -26,8 +26,14 @@ function pollJob(jobId: string): void {
       } else if (tries > 40) {
         clearInterval(timer)
       }
-    } catch {
-      /* réseau : on continue de poller */
+    } catch (err) {
+      // 4xx (hors 429) : erreur permanente (job invalide/inexistant) — jamais
+      // résolue, on arrête. Réseau/5xx (backend Render en réveil) : on continue.
+      const status = (err as { response?: { status?: number } } | undefined)?.response?.status
+      if (status && status >= 400 && status < 500 && status !== 429) {
+        clearInterval(timer)
+        useAppStore.getState().appendConsoleLines([{ k: 'sys', t: 'Statut du job indisponible — suivi arrêté.' }])
+      }
     }
   }, 3000)
 }
@@ -84,7 +90,19 @@ export function useBlockRunner() {
         // remontent via callbacks vers le job.
         try {
           const job = await executePipeline(pipelineId)
+          if (!job?.id) {
+            // Job non sérialisé (régression) : ne pas poller un id fantôme
+            useAppStore.getState().appendConsoleLines([{ k: 'sys', t: 'Exécution lancée sans identifiant de job — statut indisponible.' }])
+            useAppStore.getState().failRun()
+            return
+          }
           useAppStore.getState().setLastJob(job)
+          if (job.status === 'error') {
+            // Échec immédiat (ex. location GPU refusée) : message backend, pas de polling
+            useAppStore.getState().appendConsoleLines([{ k: 'sys', t: `Exécution en erreur : ${job.error || 'inconnue'}` }])
+            useAppStore.getState().failRun()
+            return
+          }
           pollJob(job.id)
         } catch {
           useAppStore.getState().appendConsoleLines([{ k: 'sys', t: "Échec du lancement de l'exécution." }])

openspec/changes/run-error-handling/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-08-12

openspec/changes/run-error-handling/design.md

@@ -0,0 +1,44 @@
+## Context
+
+La route `execute_pipeline` (routes.py) crée le job, génère le code, tente la location Vast (ou lance le subprocess local), puis `session.commit()` et `return job`. SQLAlchemy/SQLModel a `expire_on_commit=True` par défaut : après `commit()`, le `__dict__` de l'instance est vidé et les attributs ne sont rechargés que lors d'un accès (lazy) ou d'un `refresh()`.
+
+Reproduction prouvée : mode gpu + rent refusé (400 insufficient_credit) → `execute` répond `200 {}` (0 champ) alors que `get_job` (session.get) répond `200` avec les 11 champs. `session.refresh(job)` avant sérialisation → 11 champs. La branche locale « survivait » par accident : l'accès `job.id` après le commit (ligne `job_id = job.id`) rechargeait l'instance avant le return.
+
+Côté frontend : `useBlockRunner.onRun` appelle `pollJob(job.id)` sans vérifier `job.id` ni `job.status` → avec un job vide, `pollJob("undefined")` boucle sur `GET /api/jobs/undefined → 422` (le catch continue indéfiniment, seule la limite `tries > 40` arrête après 120 s), et `finishRun(build)` est appelé juste après → faux succès.
+
+## Goals / Non-Goals
+
+**Goals:**
+- `execute` retourne toujours un job sérialisé complet (id, status, error).
+- Le frontend affiche l'erreur du job (ex. « Location GPU Vast.ai impossible… ») immédiatement, sans polling ni faux succès.
+- Le polling s'arrête sur les erreurs permanentes (4xx).
+
+**Non-Goals:**
+- Changer le comportement de `get_session` globalement (`expire_on_commit=False`) — impact large, non nécessaire.
+- Modifier le message d'erreur backend existant (déjà en français et pertinent).
+- Gérer les erreurs GPU côté Vast (location) — hors périmètre, le backend les traduit déjà en job error.
+
+## Decisions
+
+### D1 — `session.refresh(job)` avant chaque return de `execute_pipeline`
+Les 3 retours (branche local, dummy gpu, dispatched gpu) rechargent l'instance depuis la DB avant le `return job` → la sérialisation FastAPI est complète.
+*Alternatives* : `expire_on_commit=False` sur la session (impact global, risque de lectures stale) ; retourner un dict construit manuellement (duplique le schéma). Refresh : localisé, standard.
+
+### D2 — Frontend : pas de polling sur job invalide ou déjà en erreur
+Dans `onRun`, après `executePipeline` :
+- `!job?.id` → console « statut de l'exécution indisponible » + `failRun`, return (aucun polling).
+- `job.status === 'error'` → console « Exécution en erreur : {job.error} » + `failRun`, return (le cas budget — affiché sans attendre le polling).
+- Sinon → `setLastJob(job)` + `pollJob(job.id)`.
+`failRun` met l'état d'échec global (running=false) — cohérent avec les autres chemins d'erreur.
+
+### D3 — `pollJob` : arrêt net sur 4xx
+Dans le `catch` de `pollJob` : si `err.response?.status` est un 4xx hors 429 → `clearInterval` + console « job introuvable/statut indisponible » (erreur permanente, jamais résolue). Réseau/5xx → comportement actuel (continuer, limite `tries > 40`).
+
+### D4 — Test de régression backend
+Test unitaire : `execute_pipeline` (mode gpu mocké — `launch_instance` force dummy) retourne un JSON avec `id` non vide et `status` (error). Le mock remplace `VastAI.launch_instance` pour éviter tout appel réseau réel.
+
+## Risks / Trade-offs
+
+- **Refresh = requête DB supplémentaire** par exécution — négligeable (1 SELECT par run).
+- **Job déjà en erreur au retour** : le frontend n'appelle plus jamais `getJobOutputs` pour ce job (l'erreur de location n'a pas de sorties) — comportement souhaité.
+- **4xx dans pollJob** : un 401/403 (clé expirée) arrêterait aussi le polling — acceptable (erreur permanente, pas de résolution sans action utilisateur).

openspec/changes/run-error-handling/proposal.md

@@ -0,0 +1,14 @@
+## Why
+
+Quand une exécution GPU échoue (ex. pas de budget Vast.ai), le backend met le job en `error` avec un message clair, mais **le frontend reçoit un job vide** : la route `execute` sérialise l'instance SQLModel après `commit()`, or SQLAlchemy l'expire (expire_on_commit) → réponse `{}` → le frontend poll `GET /api/jobs/undefined` en boucle (422) et affiche un faux succès (« Build réussi ») au lieu de l'erreur réelle. Root cause reproduite en local : `execute → 200 {}` vs `get_job → 200 {11 champs}` ; `refresh` avant sérialisation restaure les 11 champs.
+
+## What Changes
+
+- **Backend** : `session.refresh(job)` avant chacun des 3 `return job` de `execute_pipeline` — l'instance retournée est complète (id, status, error…). Les autres routes sont déjà saines (create/update font refresh).
+- **Frontend** : `useBlockRunner` — après `executePipeline`, ne pas lancer le polling sur un job invalide (`!job?.id`) ni sur un job déjà en erreur (`status === 'error'`) ; afficher l'erreur du job immédiatement (console + état échec). `pollJob` s'arrête net sur erreur 4xx (hors 429) — un 422 ne se résoudra jamais ; les erreurs réseau/5xx continuent (wake-up Render) avec la limite existante.
+- **Test de régression** : `execute` retourne un job sérialisé complet (id présent) en mode gpu avec rent en échec (mocké).
+
+## Capabilities
+
+### New Capabilities
+- `run-error-handling`: gestion des erreurs d'exécution de pipeline côté API (sérialisation du job) et frontend (affichage immédiat de l'erreur, arrêt du polling sur job invalide).

openspec/changes/run-error-handling/specs/run-error-handling/spec.md

@@ -0,0 +1,38 @@
+## ADDED Requirements
+
+### Requirement: Exécution retourne un job sérialisé complet
+Le backend SHALL retourner le job complet (id, status, error, vast_instance_id…) dans la réponse de `POST /api/pipelines/{id}/execute`, y compris quand l'exécution échoue (ex. location GPU refusée).
+
+#### Scenario: Échec de la location GPU
+- **WHEN** le rent Vast échoue (crédit insuffisant, offre introuvable) et que le job passe en `error`
+- **THEN** la réponse de execute contient `id` (UUID non vide), `status: "error"` et le message d'erreur français
+
+#### Scenario: Exécution locale
+- **WHEN** le pipeline s'exécute en mode local
+- **THEN** la réponse de execute contient l'`id` du job et `status` (queued/dispatched)
+
+### Requirement: Le frontend affiche l'erreur d'exécution immédiatement
+Le frontend SHALL afficher l'erreur du job (message `job.error`) dans la console et passer en état d'échec sans lancer le polling, quand le job retourné par execute est déjà en `error` ou n'a pas d'`id` valide.
+
+#### Scenario: Job en erreur dès le retour
+- **WHEN** `executePipeline` retourne un job avec `status: "error"` (ex. location GPU refusée)
+- **THEN** la console affiche « Exécution en erreur : {job.error} » et l'UI passe en état d'échec, sans polling
+
+#### Scenario: Job sans identifiant
+- **WHEN** `executePipeline` retourne un objet sans `id` valide
+- **THEN** la console indique que le statut est indisponible et l'UI passe en état d'échec, sans polling
+
+#### Scenario: Job en cours
+- **WHEN** `executePipeline` retourne un job valide non terminé
+- **THEN** le polling du job démarre normalement
+
+### Requirement: Le polling s'arrête sur erreur permanente
+Le polling de job (`pollJob`) SHALL s'arrêter sur une erreur HTTP 4xx (hors 429) — un job invalide ou inexistant ne se résoudra jamais — et SHALL continuer sur les erreurs réseau/5xx (reprise du backend) jusqu'à la limite existante.
+
+#### Scenario: Job invalide (422)
+- **WHEN** le polling reçoit une réponse 4xx (hors 429) pour le job
+- **THEN** le polling s'arrête et un message de statut indisponible est affiché
+
+#### Scenario: Backend en veille (5xx/réseau)
+- **WHEN** le polling reçoit une erreur réseau ou 5xx (backend Render en réveil)
+- **THEN** le polling continue jusqu'à la limite de tentatives existante

openspec/changes/run-error-handling/tasks.md

@@ -0,0 +1,17 @@
+## 1. Backend
+
+- [x] 1.1 `routes.py` execute_pipeline : `session.refresh(job)` avant les 3 `return job` (branche locale, dummy gpu, dispatched gpu)
+- [x] 1.2 Test de régression : `execute` (mode gpu, `launch_instance` mocké → dummy) retourne un JSON avec `id` non vide + `status` (error) — dans test_server.py
+
+## 2. Frontend
+
+- [x] 2.1 `useBlockRunner.onRun` : après `executePipeline` — `!job?.id` → console « statut indisponible » + failRun ; `job.status === 'error'` → console « Exécution en erreur : {job.error} » + failRun ; sinon setLastJob + pollJob
+- [x] 2.2 `pollJob` : dans le catch — arrêt net + message si `err.response?.status` est 4xx hors 429 ; sinon continuer
+- [x] 2.3 Build frontend : `npm run build` OK
+
+## 3. Validation
+
+- [x] 3.1 Backend : reproduction locale (mode gpu, clé réelle, rent refusé) — `execute` répond avec `id` + `status: error` + message FR
+- [x] 3.2 Suite pytest : 92 + nouveaux, 7 pré-existants `/api/blocks*`
+- [x] 3.3 Smoke navigateur : run sur Render → erreur de location affichée dans la console (pas de faux succès, pas de boucle 422)
+- [x] 3.4 Commit + push dev/chedli + fast-forward main