Verificare il canale eseguito

In breve

Un canale non coincide con il nome di un prodotto. È la combinazione di risolutore, entry point, versione, configurazione, trasporto e directory di lavoro. Se il probe cambia anche uno solo di questi elementi, sta verificando un altro sistema. La prova minima deve quindi chiedere al resolver del launcher quale canale verrà usato, avviarlo nello stesso modo e osservarne una capacità dichiarata.

Identità del canale

Un report ripetibile registra un’identità logica, non dettagli personali dell’host:

{
  "channel": "worker-via-companion",
  "entryPoint": "resolved-package",
  "capability": "minimal-read",
  "result": "pass"
}

Il percorso fisico completo può restare nella diagnostica locale. Nell’evidenza condivisa bastano alias, versione normalizzata, capacità, esito e durata. Modello ed effort vanno inclusi solo se fanno parte della proprietà verificata; i valori sensibili non appartengono mai al report.

Una scala di probe

Livello	Domanda	Esempio di asserzione
Risoluzione	quale entry point partirà?	target canonico, non copia di sviluppo
Struttura	il pacchetto è completo?	risorse companion presenti e leggibili
Handshake	il trasporto risponde?	risposta valida entro il timeout
Capacità	il canale svolge l’azione minima?	lettura sintetica con esito atteso
Ciclo di vita	lascia processi o lock?	nessun residuo posseduto dopo la chiusura

Ogni livello aggiunge informazione e conserva l’esito dei precedenti. “File presente” non diventa mai “canale pronto”. Il probe di capacità usa la stessa precedenza dei parametri del task e una risorsa sintetica. Se l’azione modifica stato, deve operare in un perimetro temporaneo dichiarato e lasciare la pulizia al proprietario del test.

Il verde sulla copia sbagliata

In un’integrazione reale, la verifica lanciava il bridge contenuto nel clone di sviluppo. Il worker usava invece il bridge installato nella cache del plugin, con versione e ciclo di vita diversi. Il check era verde anche quando il canale operativo non rispondeva. Dopo il fix, verifica e launcher chiamano lo stesso resolver; la presenza del clone resta un controllo di inventario, separato dal probe.

Un altro guasto rende evidente il valore della stratificazione: il client diretto completava il probe, mentre il companion restava in attesa per un processo residuo. Verificare “il prodotto” avrebbe nascosto la causa. Verificare i due canali ha isolato il difetto nel companion. La procedura concede un secondo tentativo distanziato per assorbire lock transitori, poi classifica il silenzio come errore; non trasforma retry indefiniti in un successo.

Evidenza diagnostica

Un record utile contiene timestamp, identità logica, livello raggiunto, durata, codice di esito e categoria dell’errore. Non contiene prompt, transcript, token o configurazioni complete. Questo segue il principio black-box descritto in Google SRE: Monitoring Distributed Systems: osservare il comportamento visto dal chiamante. I segnali interni restano un secondo livello diagnostico, non sostituiscono l’effetto esterno.

Nel setup verificabile il probe è una fase obbligatoria: installazione e verifica condividono il resolver, ma producono evidenze diverse.

Limiti

Un probe non copre ogni combinazione di rete, autorizzazioni e concorrenza. Timeout e retry possono mascherare problemi intermittenti se non sono riportati. Anche un check verde è una fotografia: dimostra una capacità precisa su un canale preciso, non l’affidabilità futura del servizio né la correttezza di un task più ampio.

Voci correlate

• Setup verificabile degli agenti
• Precedenza dei parametri
• Invarianti di fiducia

Fonti

• Google SRE: Monitoring Distributed Systems, riferimento generale su osservazione black-box e white-box; non rende sufficiente un probe specifico.
• OpenTelemetry: Traces, riferimento per correlare operazioni e segnali diagnostici; non prescrive la regola dell’esatto canale.