Rilevare errori javascript su sito in produzione

[Stefano Bagnara]

Ciao a tutti,

nel deploy della nuova versione di VOXmail stiamo ricevendo delle
segnalazioni da alcuni clienti (2 o 3 su qualche migliaio) che da
quello che ci descrivono ipotizziamo abbiano un errore javascript che
impedisce a tutti i popup/dropdown/validatori e altro che dipende da
javascript di funzionare.

Visto che non riusciamo a riprodurre il problema in nessun ambiente
per il momento ci siamo preoccupati di poterlo misurare e la prima
cosa che abbiamo trovato è stata http://bugsnag.com che abbiamo già
messo su e stiamo testando da qualche ora nella versione trial.

Il sistema ci ha già rilevato un paio di problemi "non bloccanti" e in
questo senso è già stato molto utile, ma per ora ancora non abbiamo
rilevato la casistica che impedisce completamente l'uso della nostra
versione a quei 2-3 clienti (anche perchè non sono clienti skillati e
non posso chiedere loro molto e per ora li ho rimessi sulla vecchia
versione).

Il motivo di questa mia email, oltre a condividere i miei dispiaceri
;-) , è per sapere da voi se fate monitoraggio di questi problemi sui
vostri siti/servizi e qual è la vostra strategia in tal senso?

Io per ora procedo con bugsnag.com e se vi interessa ve la recensirò
fra qualche settimana di utilizzo.

Stefano

PS: Al momento pensiamo che si tratti di un qualche
antivirus/antispam/proxy che fltra i javascript e per qualche motivo
li rompe, perchè in un file js salvato da uno dei clienti mancavano
dei commenti e c'erano degli "a capo" che nel nostro file compresso
non ci sono. Tendiamo ad escludere si tratti di un problema di
ordinamento del caricamento dei js perchè in molte pagine abbiamo un
unico js compresso. Nei 3 casi i 3 clienti usavano versioni recenti di
Chrome (33/34) su piattaforme diverse (WinXP, Win7, OSX), quindi
potrebbe essere un problema di Chrome (oppure solamente un caso):
chiaramente abbiamo testato Chrome su molteplici macchine senza
riprodurre il problema. Gli stessi clienti sulla vecchia versione di
VOXmail riescono a lavorare, quindi non hanno javascript disabilitato.

[Marco Pracucci]

Noi non siamo particolarmente bravi a tracciare errori JS, ma ecco quello che facciamo.

1. Usiamo gli eventi di Google Analytics per il tracking degli errori JS (così abbiamo implicitamente lo splitdown x browser / piattaforma / country / lingua / pagina / etc)
2. Nella label di ciascun evento tracciamo il messaggio dell'error, file e linea (se disponibile)
3. Ci registriamo a window.onerror, wrappiamo con try/catch tutti i nostri moduli JS (design: tanti piccoli moduli che piagano notifiche su un bus e ascoltano notifiche, 2 moduli non si parlano direttamente)
4. Per ridurre il rumore degli errori (tanti window.onerror sono causati da ads ed estensioni) filtriamo "file" e nel tempo abbiamo creato una lista di regex per filtrare "error.message" che non riguardano la nostra app

My cent,
Marco

Sent from my iPhone

> --
> Hai ricevuto questo messaggio perché sei iscritto al gruppo "XPUG Romagna" di Google Gruppi.
> Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a xpug-romagna...@googlegroups.com.
> Per postare messaggi in questo gruppo, invia un'email a xpug-r...@googlegroups.com.
> Visita questo gruppo all'indirizzo http://groups.google.com/group/xpug-romagna.
> Per ulteriori opzioni, visita https://groups.google.com/d/optout.

[Stefano Bagnara]

Grazie Marco,

cominciavo a pensare che fossimo gli unici ad esserci imbattuti in un
problema simile ;-)

effettivamente i punti che descrivi assomigliano molto a ciò che
avevamo ipotizzato di fare prima che decidessimo di mettere alla prova
bugsnag: abbiamo scelto la strada bugsnag perchè abbiamo ipotizzato
che potesse non essere banale legarsi al solo window.error e che
potesse diventare altra roba da rendere cross-browser e causa di nuovi
problemi.
In realtà il codice js di bugsnag abbiamo visto che è piuttosto
piccolo e quindi forse la cosa non aveva tutte le implicazioni che
avevamo ipotizzato sulle prime.

intanto io ho qualche altra ora di bugsnag sulle spalle e devo dire
che di segnalazioni ne ricevo abbastanza: il problema è che quando
comincio a ricevere delle segnalazioni tipo "$ is not defined" poi
rimango nel mio dilemma di come questo possa accadere avendo un solo
js nella pagina (o alternativamente dei syntax error in punti in cui
non ho syntax errors).

Per ora non ho errori "ricorrenti" quindi temo che bugsnag mi aiuterà
solamente a capire quanto spesso capita che un mio cliente vede una
pagina rotta ma non mi aiuterà a capirne le cause: forse se l'avessi
usato anche in passato almeno potrei sapere se questi errori sono
aumentati o sono rimasti costanti nel tempo.

Ieri ho investigato sull'estensione Avast per Chrome perchè abbiamo
ipotizzato potesse essere lei ad alterare dei nostri js ma
installandola in test non ha dato problemi.

Grazie del feedback!
Stefano

[Federico Galassi]

Il problema è che onerror per problemi implementativi non tiene l'oggetto eccezione che in browser decentemente moderni avrebbe lo stack trace. La soluzione portabile è transpilare il proprio codice aggiungendo un try catch in tutte le esecuzioni di funzioni. Mi pare che uno dei servizi lo faccia. Presumibilmente, visto il costo, l'ideale sarebbe gestire window.onerror e quando questo avviene markare il client (cookie, db locale, etc..) in modo che a seguito di un reload gli si possa servire il codice transpilato.

Voglio porre solo l'accento su 4 cose

1) come dici tu l'implementazione può non essere priva di imprevisti, quando mi son fatto la roba mia ho guardato alcuni di quegli script e alla fine mi sono fermato su un'architettura che da subito salva errori in un array e asincronamente logga remoto con l'invio di form invece che usare ajax. Anche se non ne ho le prove suppongo che la tecnica fosse stata adottata per un problema di ajax su qualche browser. Altri (newrelic) caricano un'immagine passando tutto nei parametri della query.

2) Come dice marco occhio agli errori di altri perchè onerror tira su tutto, da script terze parti ad estensioni, bookmarklet etc.. bisogna fare una qualche forma di filtro. Per mia esperienza personale questo vuol dire che non è mai una buona idea notificare qualcosa all'utente di fronte a un errore

3) Se usi roba terze parti occhio che onerror è global e pertanto chiunque può cercare di fare il tuo stesso lavoro (nel mio caso si è messo a farlo newrelic e ha smesso di funzionare il mio)

4) Il problema vero non è il logging ma è il pannello. Partizionare gli errori per browser/piattaforma, ignorare errori che conosciamo e non sono reali, etc...

Ciao
Federico

[Stefano Bagnara]

Alla fine credo di aver scoperto il problema.

Tutti i clienti sui quali bugsnag ha rilevato il syntaxerror (in varie
forme e sia da Chrome che da Firefox che da Safari) erano connessi da
IP di VODAFONE.
Dopo varie ricerche ho scoperto che Vodafone utilizza un transparent
proxy per comprimere immagini, minimizzare css e javascript e altre
operazioni di questo tipo.

In un mio javascript (aggregato e minimizzato) era presente una
sequenza di questo tipo:
--
var a = function() { .... }
!function() { ... }||...
----
Il transparent proxy di vodafone toglieva l'invio tra queste due righe
rendendo la sintassi errata:
---
var a = function() { .... }!function() { ... }||...
---

E' bastato inserire un ";" ESPLICITO in fondo alla prima definizione e
la modifica applicata dal proxy di vodafone non rompe più la sintassi.

A meno che a voi non venga in mente qualche altra conclusione io l'ho
classificato come un bug del minimizzatore usato dal transparent proxy
di Vodafone che da quello che ho capito si può risolvere in vari modi:
1) usare sempre ; espliciti perchè qualcuno potrebbe toglierti degli
"a capo" che sono necessari per far funzionare i ";" impliciti
2) mettere "Cache-Control: no-transform" nelle risposte del server
(non testato, ma leggendo in giro sembrava essere una soluzione per
evitare che Vodafone e altri transparent proxy facciano danni)
3) muovere tutto in https così che i transparent proxy non ci mettano
lo zampino.

Vorrei chiudere sottolineando come una caratteristica di un linguaggio
(punti e virgola facoltativi in molte situazioni) abbia contribuito a
creare questo bug in quanto gli sviluppatori del proxy di vodafone
avrebbero più difficilmente commesso questo errore se la sintassi di
javascript fosse stata più rigida: in javascript il ";" può essere
omesso solo se dopo c'è un invio o una graffa chiusa e probabilmente
gli sviluppatori vodafone (o quelli del software che loro usano) non
conoscevano la regolina quando hanno deciso che quell'invio poteva
essere tolto, oppure l'hanno mal interpretata.

PS: in realtà il codice che viene alterato da Vodafone ce l'avevamo
anche nella vecchia versione di VOXmail ma usavamo un aggregatore js
leggermente diverso che nell'aggregare i file metteva ";" all'inizio e
"\n" in fondo a ciascun file mentre il nuovo aggregatore mette solo i
"\n" e quindi si creava quella sequenza che sintatticamente è valida
ma che evidentemente il filtro Vodafone rompe (anche per questo motivo
identificare il problema è stato molto più difficoltoso).

E quindi adesso dovremo tutti aggiungere web testing dei nostri
servizi web connettendoci dalle varie reti dei vari operatori? La
nuova frontiera del testing?
Stefano

[Marco Pracucci]

Solo come nota: l'ho visto fare anche da operatori in US.

Sul fatto dei ";" non voglio scatenare una guerra: per noi sono sempre mandatory (altrimenti il linter non passa), ma su questo punto ci sono varie filosofie di pensiero.

Sent from my iPhone

[giulio...@gmail.com]

Stefano,

grazie per la dettagliata descrizione del problema; e complimenti per essere riuscito ad individuarlo in modo così preciso.

Giulio Cesare

[Federico Galassi]

On 29 Apr 2014, at 12:39, Marco Pracucci <ma...@pracucci.com> wrote:

> Solo come nota: l'ho visto fare anche da operatori in US.
>
> Sul fatto dei ";" non voglio scatenare una guerra: per noi sono sempre mandatory (altrimenti il linter non passa), ma su questo punto ci sono varie filosofie di pensiero.

Chiariamo che sono due cose differenti. Posso aggiungere semicolon per evitare problemi come questo del proxy marcio e posso aggiungere semicolon perchè mi piacciono perchè chiariscono il codice. Nel primo caso le posso aggiungere in fase di post processing così come comprimo, etc.. Nel secondo caso le mettono i programmatori nel codice sorgente. Io non credo nel secondo caso.

Ciao
Federico

[Stefano Bagnara]

Il 29 aprile 2014 16:33, Federico Galassi <federico...@gmail.com>
ha scritto:

>
> On 29 Apr 2014, at 12:39, Marco Pracucci <ma...@pracucci.com> wrote:
>
>> Solo come nota: l'ho visto fare anche da operatori in US.
>>
>> Sul fatto dei ";" non voglio scatenare una guerra: per noi sono sempre mandatory (altrimenti il linter non passa), ma su questo punto ci sono varie filosofie di pensiero.
>
> Chiariamo che sono due cose differenti. Posso aggiungere semicolon per evitare problemi come questo del proxy marcio e posso aggiungere semicolon perchè mi piacciono perchè chiariscono il codice. Nel primo caso le posso aggiungere in fase di post processing così come comprimo, etc.. Nel secondo caso le mettono i programmatori nel codice sorgente. Io non credo nel secondo caso.

Speravo proprio di aver acceso una miccia da flame in questo gruppo
che stava un po' dormicchiando (anche a giudicare dalle adesioni
dell'ultimo doodle) ;-)

Quello che volevo dire io è che se Javascript non avesse avuto questa
flessibilità che ti permette di omettere il ";" in certe situazioni
io, a questo giro, molto probabilmente avrei avuto meno scazzi.
La complessità della grammatica di un linguaggio è comunque da mettere
sul piatto quando si fa una valutazione dello stesso e questo è un
esempio lampante.
E' chiaro che qui la colpa non è di Javascript ma di Vodafone, ma se
Javascript non avesse permesso di omettere il ";" al 99% questo
problema non si sarebbe mai creato.

Comunque non è che javascript faccia cose particolarmente strane
rispetto agli altri: così su due piedi mi viene in mente la spaziatura
nelle operazioni matematiche.
Mi pare che molti linguaggi considerino "a + b" identico ad "a+b" ma
"a + ++b" non può essere scritto "a+++b": quindi anche qui lo spazio è
facoltativo solo in alcuni casi.
In PHP, JS, Java "a+++b" viene considerato "a++ + b".
Forse i linguaggi che non hanno la forma a++ o ++a non soffrono di
questo problema in cui la spaziatura diventa elemento di sintassi
necessario.

Sono sicuro che se approfondissimo un po' troveremmo altre cose di
questo genere più o meno evidenti: credo che ognuno abbia le proprie
preferenze dovute prevalentemente all'abitudine. Preferirei che
javascript necessitasse sempre del ";" (e da oggi ho un motivo in più)
ma allo stesso tempo non so se sarei contento di avere un errore di
sintassi ogni volta che faccio a+b senza spazi.

Stefano