historichunt / HiSTORICCacciaAlTesoro

Caccia al tesoro di HiSTORIC
GNU General Public License v3.0
1 stars 0 forks source link

Controllo Errori in Airtable #11

Open mirko-nespoli opened 3 years ago

mirko-nespoli commented 3 years ago

TODO: fare un metodo che controlli che non ci siano errori e da far girare offline PRIMA di una caccia per verificare che passi tutti i test (e magari ad ogni modifica della tabella airtable). Viene lanciato da linea di comando e da il feedback direttamente li’? (oppure dentro al bot solo per admin cosi’ chiunque puo’ controllarlo anche senza Federico ogni volta che fa una modifica?) C’e’ un solo “FINALE=Y” ed è l’ultima riga. L’ultima riga NON può avere NEXT=Y Il campo “Domanda” NON è mai vuoto. Il campo “Soluzioni” NON è mai vuoto. Il campo “Categoria” NON è mai vuoto.

kercos commented 3 years ago

Si, molto importante questo. L'ho già iniziato a implementare ma per ora funziona solo da riga di comando. Certamente è da mettere all'interno del bot. Però l'ordine delle tappe nell'airtable non è importante: l'ultima tappa non è necessariamente quella finale.

phauly commented 3 years ago

Si, molto importante questo. L'ho già iniziato a implementare ma per ora funziona solo da riga di comando. Certamente è da mettere all'interno del bot. Però l'ordine delle tappe nell'airtable non è importante: l'ultima tappa non è necessariamente quella finale.

In #10 ho copiato la "Proposta di modifica del significato del campo “NEXT” e “FINALE”" (che prima era in un google doc). Ovviamente discutiamo in #10 e non qui ;)

phauly commented 3 years ago

Inoltre vedi i vari vincoli ben scritti nel vademecum (andrebbe linkato qui direi).

Ad esempio gli asterischi devono essere in numero pari, i nomi dei file non devono avere caratteri strani ecc ecc

phauly commented 3 years ago

Quando parte questa funzione e a come da feedback a noi (sia in caso tutto ok, sia in caso di problemi)?

Sarebbe meglio se partisse ad ogni /update ad esempio e dasse feedback direttamente dentro il chatbot?

kercos commented 3 years ago

Qua il codice (incompleto) per controllo automatico di airtable: https://github.com/kercos/HiSTORICCacciaAlTesoro/blob/master/airtable_check.py

mirko-nespoli commented 3 years ago

Aggiungo qui il commento sopra, dell'inoltro dei messaggi di errore durante la caccia (non dei partecipanti, ma del bot stesso) anche ad altri utenti, o comunque visione di essi

phauly commented 3 years ago

Aggiungo qui il commento sopra, dell'inoltro dei messaggi di errore durante la caccia (non dei partecipanti, ma del bot stesso) anche ad altri utenti, o comunque visione di essi

Credo che siano due cose diverse:

  1. questo ticket si riferisce ad uno script che controlla che in airtable NON ci siano problemi che noi conosciamo (ad esempio che nei campi di testo gli asterischi devono essere in numero pari). L'idea di questo script (da capire quando farlo girare) e' di controllare che il testo inserito in airtable non sia incompatibile con le regole definite nel vademecum che ci siamo dati (e che il bot si aspetta).

  2. quello a cui ti riferisci tu, se ho ben capito, sono bachi nel codice del bot che occorrono in tempo reale (i bachi ci potranno sempre essere e non per forza sono legati a problemi con il testo dentro airtable, potrebbe essere banalmente un "finito il disco" sulla macchina virtuale in cui gira il bot o "troppe chiamate gratis ad airtable fatte"): in questo caso, quando occorrono tu vorresti che la segnalazione dell'errore arrivasse anche a persone "normali" (noi admin) e non solo come log di sistema che solo @kercos e' in grado di vedere (se e quando se ne accorge). Corretto?

Ad esempio ti riferisci a questo errore (che, se ho ben capito, @kercos ti ha mandato a seguito di tue domande su problemi/bug che pensavi ci fossero con il next nelle cacce?

❗️ Exception Traceback (most recent call last):
File "/workspace/main_exception.py", line 10, in exception_reporter_wrapper
func(*args, **kwargs)
File "/workspace/main_exception.py", line 26, in report_exception_in_thread
func(*args, **kwargs)
File "/workspace/ndb_utils.py", line 8, in client_context_wrapper
return func(*args, **kwargs)
File "/workspace/bot_telegram_dialogue.py", line 931, in deal_with_request
repeat_state(p, message_obj=message_obj)
File "/workspace/bot_telegram_dialogue.py", line 68, in repeat_state
method(user, message_obj, **kwargs)
File "/workspace/bot_telegram_dialogue.py", line 110, in state_INITIAL
game.reset_game(p, hunt_password)
File "/workspace/game.py", line 184, in reset_game
missioni = get_random_missioni(p, airtable_game_id, mission_tab_name, initial_cat)
File "/workspace/game.py", line 108, in get_random_missioni
assert next(round_robin_cat) == next_mission_cat
AssertionError

Se ti riferisci a questo secondo caso, e' una cosa diversa da questo ticket. Ha senso scriverlo in un suo ticket e, soprattutto, capire con @kercos se c'e' un modo semplice perche', quando avviene un qualunque errore (o warning) nel sistema che gestisce il bot, questo errore venga inviato a chi vuole (ad esempio a me e a te) in qualche modo (ad esempio via email, oppure via chat).

Immagino che una soluzione (semplice?) sia di fare uno script (anche bash) che legga continuamente il file di log del bot sul file system dove gira e, in caso di modifiche, invii via email (o altro) le modifiche.

phauly commented 3 years ago

(da discussione in telegram tech)

controllo da aggiungere.

eventuali campi "custom"/modificati per una specifica caccia dentro SETTINGS o UX DEVONO essere uguali a una delle "variabili" globali.

Ad esempio in una caccia, dentro SETTINGS c'era scritto "RESET_HUNT_AFTER_COMPLETION§" (NOTA il typo con un carattere speciale alla fine della stringa!) oppure dentro UX potrebbe esserci MSG_FINAL_RESET_ONNNNN (typo = troppe N alla fine).

In questi casi (1) noi non ce ne accorgiamo e pensiamo di aver fatto una modifica al comportamento di default (variabili nel codice) ma (2) il software NON usa ovviamente le variabili col typo e quindi continua a operare con il comportamento di default e noi ce ne accorgiamo (se ce ne accorgiamo) troppo tardi!

@kercos dice "si se una variabile non è scritta esattamente si potrebbe generare un errore o il bot prende il valore di default"

TODO: aggiungere questo controllo! Ovvero variabili custom in SETTINGS e UX devono matchare con quelle globali di sistema altrimenti manda un ENORME WARNING a noi!

phauly commented 3 years ago

c'era una riga vuota nella tabella ux che dava errore, questo lo segnalo a @kercos

:exclamation: Exception Traceback (most recent call last):
  File "/workspace/bot/main_exception.py", line 10, in exception_reporter_wrapper
    func(*args, **kwargs)
  File "/workspace/bot/main_exception.py", line 26, in report_exception_in_thread
    func(*args,  **kwargs)
  File "/workspace/bot/ndb_utils.py", line 8, in client_context_wrapper
    return func(*args, **kwargs)
  File "/workspace/bot/bot_telegram_dialogue.py", line 1028, in deal_with_request
    repeat_state(p, message_obj=message_obj)
  File "/workspace/bot/bot_telegram_dialogue.py", line 55, in repeat_state
    method(user, message_obj, **kwargs)
  File "/workspace/bot/bot_telegram_dialogue.py", line 104, in state_INITIAL
    game.reset_game(p, hunt_name, hunt_password)
  File "/workspace/bot/game.py", line 210, in reset_game
    hunt_ux = get_hunt_ux(p, airtable_game_id)
  File "/workspace/bot/game.py", line 83, in get_hunt_ux
    for lang in params.LANGUAGES
  File "/workspace/bot/game.py", line 83, in <dictcomp>
    for lang in params.LANGUAGES
  File "/workspace/bot/game.py", line 81, in <dictcomp>
    for r in table_rows
KeyError: 'IT'
phauly commented 3 years ago

altro controllo: che le colonne obbligatorie in airtable contengano effettivamente un valore (sarebbe anche bello mettere nel vademecum e come commento in airtable quali colonne sono obbligatorie)