Torna al changelog

v0.93.7

3 ottobre 2026

Transizioni protette durante l'ingresso in una fase, retry sicuri per le integrazioni, avviso sui prompt AI troppo generici, verifica dei pianificati sulla nuova versione — oltre a webhook in ingresso più robusti, invio email più affidabile e import di mappe più resistente ai tentativi ripetuti: una pratica che sta ancora completando l'ingresso in una fase non può più essere spostata da un secondo tentativo in arrivo nello stesso istante (REST, estensione e MCP ricevono un errore ritentabile, con l'indicazione di quanto attendere); REST e gli assistenti MCP possono ora dichiarare da quale fase pensano di partire, così un retry su un esito di rete incerto non rischia di muovere due volte la stessa pratica; un task AI con un prompt vuoto o senza alcun segnaposto riceve un avviso — nel pannello del task e alla pubblicazione del flusso — che richiama l'attenzione sui dati inviati al modello; un pianificato che si riaggancia a una nuova versione pubblicata viene riverificato sui controlli di creazione (limite di lavoro in corso, unicità, dati, titolo): se la nuova versione non li supera, la pratica resta sulla versione di partenza invece di nascere con una configurazione che non avrebbe superato quei controlli. Il budget di banda dei webhook in ingresso segue ora i byte davvero ricevuti, non la dichiarazione del mittente, e un rifiuto anticipato chiude subito la connessione; l'invio via SMTP riprova sugli altri indirizzi di un server a doppia pila quando il primo rifiuta la connessione; l'import di una Process Map con requestId resiste meglio a un tentativo che resta bloccato troppo a lungo o incontra un errore proprio alla fine.

  • Sicurezza

    Budget dei webhook in ingresso: il conteggio segue i byte reali, non la dichiarazione

    Il tetto di banda per organizzazione sui webhook in ingresso contava finora il Content-Length dichiarato dal mittente, anche quando il corpo non arrivava mai: chi conosceva l'indirizzo di un webhook attivo poteva esaurire il budget dell'intera organizzazione con poche decine di richieste di sole intestazioni, senza mai inviare un payload reale. Ora il conteggio segue sempre i byte effettivamente ricevuti. Le risposte di rifiuto anticipato dei webhook (indirizzo non riconosciuto o budget esaurito) chiudono inoltre subito la connessione invece di lasciarla aperta.

  • Sicurezza

    SMTP: l'invio prova anche gli altri indirizzi di un server a doppia pila

    Quando il server SMTP configurato (proprio del tenant, o dell'installazione) risolve a più indirizzi IP, l'invio provava a connettersi solo al primo: se quell'indirizzo rifiutava la connessione, l'email non partiva anche quando un altro indirizzo dello stesso server avrebbe funzionato. Ora, con la stessa validazione di sicurezza sull'indirizzo di destinazione, un rifiuto di connessione fa riprovare sugli altri indirizzi disponibili prima di segnalare l'invio come fallito; un errore successivo (per esempio credenziali sbagliate) non ritenta, perché non è un problema di indirizzo.

  • Miglioramento

    Import di una Process Map più robusto ai tentativi ripetuti

    Importare una Process Map con una chiave di richiesta (requestId) proteggeva già dal creare due volte la stessa mappa su un doppio invio — ma se un tentativo restava bloccato troppo a lungo (per esempio un disco lento, non un'intelligenza artificiale: qui non ne viene chiamata nessuna) dopo aver già creato la mappa, o l'ultimo passaggio incontrava un errore proprio alla fine, un retry successivo poteva, in casi rari, finire per creare una seconda mappa senza che nulla lo segnalasse. Ora un tentativo rimasto bloccato troppo a lungo dopo aver creato la mappa viene riconosciuto come tale: un retry con la stessa chiave riceve un errore dedicato con l'id della mappa già creata, non una ripetizione del lavoro. Un errore proprio sull'ultimo passaggio chiude invece per sempre quella richiesta (va rifatta con una chiave nuova) invece di lasciarla in un limbo che un retry avrebbe ripreso in modo scorretto.

  • Miglioramento

    Transizioni protette mentre una fase sta ancora entrando

    Nell'istante in cui una pratica entra in una nuova fase, il motore prepara i task d'ingresso e valuta le regole automatiche: se una transizione manuale (dall'interfaccia, dall'estensione o da un'integrazione MCP) arrivava esattamente in quella finestra, poteva trovare la pratica a metà di quella preparazione. Ora una transizione manuale che arriva mentre l'ingresso è ancora in corso riceve un errore ritentabile — ripetere la richiesta quando l'ingresso nella fase è completato (nei casi normali è una questione di pochi secondi) risolve — invece di rischiare di agire su una fase non ancora pronta. (La forzatura Admin resta un'eccezione deliberata: scavalca anche questo controllo, come già scavalca task bloccanti e campi obbligatori.)

  • Miglioramento

    Retry sicuri sulle transizioni per le integrazioni

    Un'integrazione che non riceve una risposta chiara a una richiesta di transizione (per esempio per un problema di rete) ora può ripeterla dichiarando da quale fase pensava di partire: se la pratica è già altrove — perché il primo tentativo in realtà era riuscito, o perché qualcun altro l'ha mossa nel frattempo — il retry si ferma senza alcun effetto, invece di rischiare una seconda transizione indesiderata.

  • Sicurezza

    Avviso per i task AI con un prompt vuoto o senza campi dati

    Un task AI (modalità LLM) configurato con un prompt vuoto o senza alcun riferimento ai dati della pratica non delimita cosa serve davvero al modello, che riceve così più dati del necessario (entro i limiti già impostati — minimizzazione e Data Shield, dove attivi). Ora, alla pubblicazione del flusso e già nel pannello del task, un avviso richiama l'attenzione su questo caso e rimanda alle impostazioni del Data Shield — senza bloccare nulla.

  • Miglioramento

    I pianificati che si riaggancerebbero a una versione nuova vengono riverificati

    Quando un pianificato parte su una versione del flusso non più attiva e si riaggancia automaticamente all'ultima versione pubblicata, FlowSharp verifica ora che quella versione superi gli stessi controlli applicati a una pratica creata normalmente (limite di lavoro in corso, unicità, coerenza dei dati, formula del titolo). Se un controllo non passa, il pianificato resta sulla versione di partenza invece di nascere comunque su una configurazione che l'avrebbe respinto.