Salta ai contenuti

Eseguire ed eseguire il debug di uno scenario

Il pulsante di riproduzione dell’editor. È disattivato fino a quando restano errori di validazione.

Se lo scenario dichiara parametri senza valore, Restorm li chiede nel momento in cui l’esecuzione li raggiunge.

Uno scenario dopo l’esecuzione, con il pannello «Log di esecuzione» aperto a destra del grafo: la traccia con marca temporale start / done di ogni azione

Il log di esecuzione si riempie man mano. Ogni voce porta un livello (debug, info, warn, error), una marca temporale al millisecondo, un messaggio ed eventualmente dei dati strutturati.

Due livelli di dettaglio:

  • per impostazione predefinita vengono mostrate soltanto le voci prodotte dall’utente — quelle generate dall’azione Log;
  • la visualizzazione completa aggiunge le voci del motore: avvio e fine di ogni riquadro, valori in transito sui collegamenti, errori.

Il pulsante di copia del log produce esattamente lo stesso testo dell’output della riga di comando: ciò che si incolla in un ticket è identico a ciò che produrrà la CI.

Le esecuzioni vengono archiviate accanto al progetto, nello stesso file della cronologia delle risposte. Per impostazione predefinita: le ultime 50 esecuzioni, 2.000 voci di log per esecuzione, con una durata di vita di 30 minuti.

Il pulsante di arresto interrompe l’esecuzione. Le attese in corso (Attendi, Attendi fino a, Timer) si interrompono in modo pulito, le connessioni aperte vengono chiuse e le azioni di codice in corso vengono abbandonate.

I riquadri di tipo richiesta possono essere eseguiti isolatamente, senza lanciare tutto lo scenario: è il modo rapido per verificare che una chiamata parta correttamente prima di cablare il resto.

Conviene aggiungere azioni Log nei punti strategici: è il console.log del grafo, ed è ciò che si ritroverà in CI.

L’azione Toast mostra un messaggio nell’interfaccia. Utile durante la costruzione — senza effetto in modalità headless, dove l’esecuzione continua normalmente.

L’edizione Pro dà accesso al debug passo a passo: punti di interruzione sui riquadri, avanzamento controllato, ispezione dei valori in transito. Si veda Piani e funzionalità.

Ogni riquadro (tranne Uscita, Adesso e Retry) ha una porta error. Un riquadro che fallisce senza che il suo error sia cablato fa fallire l’esecuzione.

Due schemi utili:

  • Retry — racchiude una frontiera di errore: i fallimenti a valle vengono intercettati e ritentati secondo la strategia configurata (fissa, lineare, esponenziale), con un’uscita exhausted quando i tentativi sono esauriti.
  • Throw — fallisce deliberatamente, con un messaggio. È ciò che serve per far fallire un job di CI su una condizione applicativa.

Un agente IA può lanciare e monitorare uno scenario (edizione Pro): run_scenario (con params, interactive, blocking), get_scenario_run_status (che restituisce il log, le richieste di inserimento in attesa e l’albero dei sotto-run), list_scenario_runs, stop_scenario_run e answer_scenario_input. Si veda Strumenti MCP.