2.1 KiB
Barcode: logging errori e transazioni
Problema rilevato
Durante uno scarico picking list dal lettore barcode, l'operazione DB e' arrivata a buon fine ma il client ha mostrato un'eccezione. I file standard output/error erano vuoti.
Con pythonw non e' sufficiente affidarsi a stdout/stderr: eccezioni Tk, future asincrone o callback possono non arrivare al wrapper principale.
Strategia adottata
Il client barcode ora registra errori in modo esplicito su warehouse_fatal.log e su barcode_wms_launch.log.
Canali coperti:
sys.excepthookthreading.excepthookTk.report_callback_exception- exception handler del loop
asyncio - eccezioni delle operazioni asincrone barcode
- errori del repository durante movimento DB
- errori post-movimento durante ricostruzione stato UI
Transazione movimento DB
Il movimento barcode passa da BarcodeRepository.execute_legacy_move.
La batch SQL usa:
SET XACT_ABORT ON;
ed e' eseguita con:
query_json(..., commit=True)
Questo significa:
- successo: commit;
- eccezione SQL/Python: rollback automatico della transazione SQLAlchemy;
- il valore
@RCrestituito dalla stored legacy non viene interpretato come errore.
Nota importante: in sp_xMagGestioneMagazziniPallet, quando il movimento va a buon fine, @RC viene valorizzato con @@IDENTITY, cioe' con l'identificativo del movimento inserito. Quindi un valore diverso da zero e' compatibile con un movimento riuscito e non deve causare rollback.
Distinzione tra movimento e refresh UI
Dopo un movimento riuscito, il service ricostruisce il messaggio UI interrogando picking list e tracciabilita'.
Se questa fase post-movimento fallisce:
- il movimento resta valido;
- l'errore viene loggato;
- l'utente vede
Movimento eseguito. Dettagli non aggiornati.; - non viene mostrato il messaggio "transazione non completata".
Se invece fallisce la transazione vera:
- l'utente vede
Transazione non completata, ripeti l'operazione.; - il dettaglio tecnico viene scritto nel log.
File principali
runtime_support.pybarcode_client.pybarcode_repository.pybarcode_service.py