AI Agente osservabilità: dimostrazione del mancato lavoro accettato scomparso

Una coda di agenti può segnalare la profondità attesa, i lavoratori possono continuare ad emettere spans, e i contatori di lavoro completato possono continuare ad aumentare mentre un lavoro accettato è scomparso. La risposta pratica è smettere di confrontare i totali e conciliare le identità. In un'interruzione limitata, registrare ogni work id accettato e richiedere che occupi esattamente un secchio corrente: La ⊎ è importante: si tratta di un'unione disunita, non di un'aggiunta ordinaria. Un documento trovato in due secchi e' una contraddizione. Non c'è un documento riconosciuto. Un terminal o un ID attivo che non è mai stato accettato è un fantasma. Questa verifica della conservazione del lavoro non promette un'esecuzione esatta una volta, ma può dimostrare un fatto più stretto e utile: la prova del piano di controllo conta ogni unità di lavoro accettata esattamente una volta. Un totale uguale può nascondere un lavoro mancante Supponiamo che il libro d'accettazione contenga 1.000 ID. La coda, la tabella di locazione e il registro terminale contengono anche 1.000 registri in totale. Una scheda di controllo basata sul conto diventa verde. Questa aritmetica consente una cattiva sostituzione: il work 417 accettato è assente mentre è apparso il record terminale ghost 92 . I numeri corrispondono. Gli identità non lo fanno. Definire le prove al punto di interruzione t0 : A : identificativi riconosciuti come accettati a t0 o prima di esso; Q : identificatori accettati visibili in coda nell'istantanea di taglio; L : identificativi accettati con un contratto di locazione la cui scadenza è successiva a t0 ; T : ID accettati con un registro terminale riconosciuto. Allora controlla entrambe le direzioni: Il terminal ha bisogno di una politica esplicita. completed è terminale. cancelled può essere terminale quando l'annullamento è autorizzato e duraturo. dead lettered può anche essere terminale a fini di conservazione, anche se è un risultato fallito che richiede ancora attenzione. Una coda di lettere morte è utile proprio perché isola il lavoro che non è stato elaborato con successo per la diagnosi e la possibile riproduzione, come spiega la Documentazione della coda in lettere morte di Amazon SQS. Non trattare leased come uno stato senza tempo. In SQS, ricevere un messaggio non lo cancella; il messaggio diventa temporaneamente invisibile e dovrebbe diventare visibile di nuovo se non viene cancellato prima che scada la scadenza della visibilità. Le code standard utilizzano anche una consegna almeno una volta, quindi una finestra di visibilità non è un blocco esattamente una volta. Le semantica visibilità timeout documentate sono il motivo per cui l'invariante utilizza valid lease , non tutte le righe di locazione mai scritte. Eseguire la riconciliazione dei sei scenari Il dispositivo di accompagnamento rende la regola decisionale verificabile senza richiedere un broker. Contiene sei istantanee a 2026 07 27T00:00:00Z : Scenario Le prove Verdetto atteso Stati di corrente mista una fila, un contratto di locazione non scaduto, uno completato CONSERVED Svanita dopo l'accettazione Identificazione accettata senza bucket corrente MISSING In fila e completato lo stesso documento in due secche DUPLICATE STATE Leasing scaduto il contratto di locazione è terminato prima del taglio, nessuna prova di restituzione EXPIRED LEASE Terminale fantasma Identificazione completata sconosciuta bilancia il conteggio PHANTOM Annullamento esplicito l'ID accettato ha un registro annullato duraturo CONSERVED Scarica work conservation fixture.json e audit work conservation.mjs dal fascicolo di prove degli articoli, o riproduci i loro campi in una directory locale, quindi eseguire: I numeri esatti osservati sono stati: PASS significa che l'auditor ha classificato tutte e sei le apparecchiature come previsto; ciò non significa che ogni apparecchio sia stato sano. Sono stati rilevati quattro casi intenzionalmente malsani. Il caso fantasma e' l'importante trappola. Ha una ID accettata e due registri osservati: l'ID reale rimane in coda mentre un ID sconosciuto richiede il completamento. Un controllo ingenuo dell'uguaglianza può sembrare equilibrato scegliendo un aggregato da ciascun sottosistema. Invece, impostare le segnalazioni di riconciliazione dell'ID terminale non accettato. Il caso dello stato duplicato espone il problema inverso: ogni ID è conosciuto, ma lo stesso lavoro sembra pronto per un altro tentativo e già completato. Questo è anche il motivo per cui le sole tracce di messaggi non sono sufficienti. La Convegni di messaggistica OpenTelemetry distingue il ricevimento, la trasformazione e il regolamento e descrive il contesto di creazione per correlare i produttori con i consumatori. Questo contesto è una prova preziosa. Tuttavia, un periodo di tempo di processo non stabilisce da solo lo stato di coda corrente o un risultato terminale duraturo. Prendi un taglio coerente del ciclo di vita L'invariante diventa fuorviante quando i suoi input descrivono momenti diversi. Immaginate di leggere il libro di accettazione alle 12:00:00, la coda alle 12:00:03, e i risultati finali alle 12:00:08. Un lavoro può legitimamente spostarsi tra queste letture e sembrare mancato o duplicato. Utilizzare il meccanismo di coerenza più forte che il tuo stack supporta: 1. assegnare una work id immutabile, qualificata per lo spazio di nome, prima di riconoscere l'accettazione; 2. scrivere il record di accettazione in modo duraturo nella stessa transazione in cui viene effettuata la sequelazione o mantenere una relazione di outbox recuperabile; 3. catturare la coda e lo stato di leasing di un watermark, di un offset, di un'istantanea del database o di una breve barriera di osservazione; 4. includere lease expires at , non solo leased=true ; 5. aggiungere i risultati terminali con lo stesso work id , un tipo di risultato e un timestamp duraturo; 6. conciliare solo i registri le cui regole di visibilità li collocano sullo stesso lato di t0 . Se i sistemi non possono fornire un taglio coerente, restituire UNVERIFIABLE piuttosto che inventare un risultato sano. Un breve periodo di silenzio può ridurre il carico, ma non sostituisce un contratto di coerenza. Documentare la distorsione massima dell'istantanea e ritardare l'allarme fino a quando un elemento di lavoro non è rimasto anomalo oltre tale limite. Gli ID stabili sono altrettanto importanti. Un nuovo tentativo dovrebbe normalmente mantenere la work id logica e ricevere una attempt id separata. Se ogni tentativo ottiene una nuova identità di lavoro, l'audit non può distinguere un nuovo tentativo da un nuovo lavoro. Se i documenti vengono riutilizzati tra gli inquilini o le code, un registro terminale legittimo può sembrare un fantasma o soddisfare falsamente un altro lavoro. Un contratto di locazione scaduto merita il suo verdetto. Potrebbe essere già visibile nel broker di nuovo, ma una vecchia riga di locazione non può dimostrare che la transizione. Richiedere nuove prove di fila o una nuova generazione di contratto di locazione prima di chiamarlo attivo. Ciò mantiene l'attesa separata dall'impostazione: un contratto di locazione valido può rappresentare lavoro; il lavoro in fila può rappresentare un'attesa legittima; un contratto di locazione scaduto senza ritorno osservato è irrisolto. Mappa ogni verdetto a una risposta limitata L'audit dovrebbe preparare l'indagine, non lanciare un'ampia riproduzione. Per MISSING , verificare prima la distorsione degli istantanei, quindi ispezionare il limite di accettazione e qualsiasi casella di invio transazionale. Conserva le prove prima di riprovare. Ricreare un lavoro da un registro incompleto può duplicare un effetto esterno. Per la DUPLICATE STATE , fermare il ritiro automatico di tale ID se la coda consente un ritiro reversibile. Confronta le prove terminali con qualsiasi ricevuta di effetto prima di decidere se la copia in fila è obsoleta. Una sola etichetta terminale può essere sbagliata; un elemento di coda ancora visibile può anche essere una replica ritardata. Per EXPIRED LEASE , chiedere al broker una nuova visibilità e controllare la generazione di lavoratori. Un riaffitto limitato può essere sicuro solo dopo che il titolare precedente è circondato o dimostrato morto. L'audit di conservazione rileva lo stato non risolto; non autorizza il recupero. Per PHANTOM , verificare lo spazio di nome ID, i bug di ingestione e la provenienza del terminal ledger. Non cancellare il record sconosciuto solo per rendere l'equilibrio dell'equazione. Potrebbe essere un valido lavoro da un altro inquilino, fila o finestra di osservazione. Infine, la conservazione non è la qualità del risultato. Un registro completed può comunque indicare un prodotto mancato o non corretto. Se possibile, seguire questo test del ciclo di vita con verifica deterministica dei risultati. I due controlli rispondono a domande diverse: È stato contabilizzato ogni lavoro accettato? e Ha prodotto il risultato previsto? Sidewisp è attualmente in anteprima privata. La raccolta dell'agente di produzione sanità, gli adattatori di coda e il recupero in tempo di esecuzione non vengono generalmente spediti. La conservazione del lavoro è un esempio delle prove che un futuro strato sanitario potrebbe valutare; non è un'affermazione che Sidewisp raccolga attualmente questi registri o agisca su agenti vivi. La mossa utile a breve termine è quella di identificare gli strumenti di lavoro stabili e testare l'invariante localmente prima di aggiungere qualsiasi risposta automatica.