Domanda su obbligatorietà verifica DRL / possibilità di posticipare il primo download

[DevTrevi]

Buongiorno a tutti,

attualmente in DgcReader quando viene richiesta la validazione di un greenpass, la libreria consente l'utilizzo di valori non aggiornati, avviando il download degli aggiornamenti di certificati, regole e blacklist in un task in background, fornendo quindi un risultato immediato all'utilizzatore e causando un leggero ritardo nell'utilizzo di valori aggiornati (in pratica, è come se si posticipasse per il tempo necessario al download la scadenza di tali valori, dato che la richiesta di validazione avvierebbe il download, e solo la richiesta successiva potrebbe utilizzare effettivamente i valori aggiornati).

Se però tali valori fossero più vecchi di una soglia limite, definita come MaxFileAge, oppure se nessun valore fosse disponibile (download mai eseguito), allora verrebbe comunque atteso il completamento del download prima di fornire un risultato.

Questo comportamento non causa problemi con certificati e regole, che richiedono pochi secondi per il completamento del download, mentre l'aggiornamento della blacklist al primo download può richiedere anche alcuni minuti.

Mi viene chiesto di consentire di poter saltare l'attesa sul download della blacklist al primo utilizzo, avviando il download in background ma fornendo quindi un risultato senza che la DRL sia stata verificata. Nella Documentazione per la DGC Revocation List leggo:

1. la verifica della DRL dovrebbe essere implementata come uno step opzionale del processo, in maniera tale che il suo stato possa essere guidato da un apposito configuration item propagato tramite la Piattaforma Nazionale; 2. il mancato aggiornamento della DRL implica una visione potenzialmente non corretta e non completa dell'insieme dei DGC prodotti dalla Piattaforma Nazionale, per tanto dovrebbero essere previsti dei controlli sullo stato di aggiornamento della DRL in grado di inibire la scansione dei DGC

Mi chiedevo quindi se lo step di verifica della DRL potesse essere considerato "opzionale" o comunque non bloccante, in modo da poter posticipare il download e consentire una validazione quasi immediata al primo utilizzo. In questo caso, potrei aggiungere un parametro opt-in che consentirebbe questo comportamento, ma non sono certo che questo sia conforme al comportamento previsto

[rawmain]

Buongiorno @DevTrevi

Mi viene chiesto di consentire di poter saltare l'attesa sul download della blacklist al primo utilizzo, avviando il download in background ma fornendo quindi un risultato senza che la DRL sia stata verificata. [...] In questo caso, potrei aggiungere un parametro opt-in che consentirebbe questo comportamento, ma non sono certo che questo sia conforme al comportamento previsto

Come hai già immaginato, la possibilità di una tale opzione anche in ambito d'uso produzione/release (non solo debug/test) non è infatti conforme a prescrizioni + istruzioni operative.

In ambito produzione/release la validazione DGC/CRT non deve essere consentita se - oltre a Validation Rules + KIDS - non sia stato completato correttamente anche DRL fetch/sync in 1st Run o dopo reset DB.

Idem anche qualora sia rilevata nuova disponibilità di DRL diff/snapshot in esecuzione scheduler/worker per controllo/aggiornamento periodico.

---

Per il resto, ho letto la issue da cui origina tale richiesta, che ti è stata sottoposta.

Vedo che il delay riscontrato con l'attuale release DgcReader & segnalato dall'utente con sua specifica impostazione app+librerie, seppur superiore ai 60s, è intorno ai 3 minuti.

Peraltro, avvenendo solo in caso di run con DB vuoto (ergo, 1st run o reset), non influenza cmq le performance delle successive operazioni.

Non vedo quindi motivazioni (tecniche e non solo), onde consentire - anche in config produzione/release - un tale override di quanto disposto da prescrizioni + istruzioni operative.

Corretto invece - come hai anche indicato all'utente nella issue - aggiungere alla libreria esposizione/event di notifica del progresso fetch/sync DRL, onde consentire maggior evidenza di tale processo lato UI/applicazione con elementi grafici e/o testuali (stile quanto fa DGC-SDK Android-Kotlin per la whitelabel-app VerificaC19).

[DevTrevi]

Grazie mille per il chiarimento @rawmain, a questo punto implementerò solo la notifica del progresso.

Per quanto riguarda il comportamento per i successivi aggiornamenti, pensi sia accettabile la strategia utilizzata, ovvero consentire l'utilizzo di valori "scaduti" mentre vengono scaricati i valori aggiornati?

[rawmain]

Ciao @DevTrevi

Grazie mille per il chiarimento

Prego ;).

Per quanto riguarda il comportamento per i successivi aggiornamenti, pensi sia accettabile la strategia utilizzata, ovvero consentire l'utilizzo di valori "scaduti" mentre vengono scaricati i valori aggiornati?

In ambito produzione la validazione con DB locale non allineato, cioè con entry DRL da versione anteriore a quella dell'ultimo snapshot disponibile online, è ammessa solo finché il client non effettui il controllo online aggiornamenti (automatico periodico con schedule <=24h o forzato manualmente da operatore) & rilevi contestualmente la disponibilità della nuova versione.

Pertanto, se il client rileva comunque l'effettiva disponibilità di una nuova versione DRL online rispetto a quella in DB locale, allora deve essere inibito l'avvio di acquisizione QR / stringa qrcodetext per validazione DGC/CRT, finché non risultino completati correttamente fetch DRL diff/snapshot & DB reconciliation.

[DevTrevi]

Capito, quindi in pratica il parametro

/// <summary>
/// If true, allows to use the current values without waiting for the refresh task to complete.
/// Otherwise, if the list is expired, every rules valdation request will wait untill the refresh task completes.
/// </summary>
public bool UseAvailableValuesWhileRefreshing { get; set; } = true;

non dovrebbe essere consentito, oppure potrebbe essere consentito solo se la nuova versione viene rilevata a distanza inferiore di 24h dal precedente download (in questo caso è come se il client non fosse ancora venuto a conoscenza dell'aggiornamento)?

Mi rendo conto che è una forzatura delle specifiche, ma questa opzione consente di mantenere tempi di risposta molto rapidi e prevedibili, soprattutto in scenari server con richieste di validazione simultanee, causando tipicamente un ritardo nell'utilizzo di valori aggiornati di pochi secondi.

Anche i provider dei certificati di firma e delle regole utilizzano la stessa logica, anche per questi non dovrebbe essere consentita questa strategia a tuo avviso?

[rawmain]

Ciao @DevTrevi

public bool UseAvailableValuesWhileRefreshing { get; set; } = true;

non dovrebbe essere consentito, oppure potrebbe essere consentito solo se la nuova versione viene rilevata a distanza inferiore di 24h dal precedente download (in questo caso è come se il client non fosse ancora venuto a conoscenza dell'aggiornamento)?

Tenendo cmq conto delle condizioni per consentire esecuzione verifiche offline - valide tanto per VerificaC19 quanto per SDK/Lib terze - le istruzioni operative possono solo limitarsi ad indicare di minimizzare il numero di validazioni effettuate con valori obsoleti di Rules / KIDs / DRL. L'unico modo per azzerarle sarebbe infatti subordinare ogni validazione a controlli preliminari di fetch/sync...

L'impostazione true/false di tale flag & le opzioni di pianificazione fetch/sync dipendono perciò da scenario/carico d'uso & grado (desiderato/vincolato) di minimizzazione, come hai anche indicato nelle note specifiche di config per uso DgcReader in validazioni ITA.

In base a tale quadro ci può quindi stare - anche in ambito di verifiche manuali/handheld - un'impostazione meno rigida & disruptive per gestione/ottimizzazione flussi di acquisizione->validazione, come appunto l'impostazione del value true (invece di false) per tale flag.

In tal caso suggerirei cmq di implementare anche esposizione/event di notifica qualora chunk totalSizeInByte > 5 MB (ved. valore da response ispettiva), sempre nell'ottica di maggior evidenza dei processi DRL lato UI/applicazione, nonché per consentire possibilità di valutazione/intervento all'operatore in virtù di relativo dismissable alert.

[DevTrevi]

Perfetto, come sempre ti ringrazio per l'aiuto, avevo il dubbio di dover eliminare del tutto questa opzione. Esporrò degli eventi di notifica e eventualmente cambierò il default di questa opzione in modo che risulti opt-in, onde evitare ritardi negli aggiornamenti non desiderati 👍