fix: staffMonitor pill visibility — robust parsing, error logging, fuzzy flight matching

[Copilot]

Stand/gate/checkin/belt pills introduced in v1.3.4 were never visible due to silent fetch failures, an overly strict HTML row filter, and fragile exact-string flight number matching.

What Changed

src/utils/staffMonitor.ts

• console.warn on non-2xx HTTP response; console.error in catch (previously swallowed silently)
• Row filter regex updated from two exact-quote checks to a single permissive pattern — matches clsFlight as a substring of the class attribute, tolerating extra classes, attribute spacing, and either quote style:

  // before
  !/class="clsFlight"/i.test(rowHTML) && !/class='clsFlight'/i.test(rowHTML)
  // after
  !/class\s*=\s*["'][^"']*clsFlight[^"']*["']/i.test(rowHTML)

• __DEV__ log: parsed count + first 5 flight numbers after each fetch

src/screens/FlightScreen.tsx

• Added fuzzy fallback match (normalizeForMatching: strips spaces/hyphens/underscores, uppercases) when the exact normalised flight number has no hit in the staffMonitor pool
• __DEV__ log when a flight card finds no match despite a non-empty pool, showing both the normalised and stripped forms for easy comparison

Checklist

• I tested the main behavior
• I verified that typecheck passes
• I updated any relevant documentation
• I checked possible Android / Wear OS impact

Screenshot or Video

No UI changes — pills already existed, this restores their data source.

Review Notes

• The fuzzy fallback only fires when the exact match misses, so no regression risk for flights that already matched correctly.
• normalizeForMatching is defined inline inside the render callback; could be extracted to staffMonitor.ts if reuse is needed later.
• All __DEV__ logs are stripped from production builds.

Original prompt

Problema

In FlightScreen.tsx, le pill arancioni con stand, gate, check-in e belt (provenienti da staffMonitor.ts) non vengono mai visualizzate nonostante il commit v1.3.4 le abbia introdotte.

Le cause identificate sono:

1. Errori silenziosi nella fetch

In src/utils/staffMonitor.ts, il blocco catch ritorna semplicemente [] senza loggare nulla:

} catch {
  return [];
}

Se la chiamata HTTP fallisce (CORS, rete, URL errato), non si sa perché.

2. Match del numero di volo fragile

Il match in FlightScreen.tsx è un'uguaglianza esatta:

staffMonitorDeps.find(sm => sm.flightNumber === normFn)

Se il formato del numero di volo dello staffMonitor differisce minimamente da quello di FR24 (es. spazi, maiuscole/minuscole, prefissi diversi), il match fallisce silenziosamente e la pill non viene mostrata.

3. Parsing HTML fragile

Il filtro delle righe cerca class="clsFlight" con virgolette doppie o singole, ma potrebbe non catturare varianti con attributi extra, spazi o formati leggermente diversi.

4. Nessun fallback visivo

Se lo staffMonitor non restituisce dati, l'utente non ha alcun feedback visivo che indichi "dati non ancora disponibili" o "caricamento in corso".

---

Interventi richiesti

src/utils/staffMonitor.ts

1. Aggiungere logging con console.warn / console.error nei blocchi catch e quando la risposta HTTP non è OK, per facilitare il debug.
2. Rendere il parsing HTML più robusto: usare una regex più permissiva per trovare clsFlight (es. clsFlight come sottostringa dell'attributo class, non solo match esatto con virgolette doppie/singole).
3. Loggare in __DEV__ il numero di risultati parsati e un campione dei numeri di volo trovati.

src/screens/FlightScreen.tsx

1. Rendere il match del numero di volo più tollerante: confrontare i numeri normalizzati (già fatto con normalizeFlightNumber) ma aggiungere anche un fallback che confronta ignorando spazi e caratteri speciali.
2. Loggare in __DEV__ quando un volo non trova corrispondenza nello staffMonitor, per aiutare il debug.

---

Note

• Non modificare la UI o la logica di business esistente, solo migliorare robustezza e diagnostica.
• Mantenere la compatibilità con il codice esistente.
• Usare if (__DEV__) per i log di debug in modo che non appaiano in produzione.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Ciao, mi controlli come mai non vedo il numero di gate, stand e checkin nonostante l'aggiornamento?

Assistant: Il repository rilevante sembra essere FlightWorkApp. Ora cerco le issue o i commit recenti legati a gate, stand e check-in.

User: Che succ

Assistant: Sembra che il repository più rilevante per la tua domanda sia FlightWorkApp (TargetMisser/FlightWorkApp), che gestisce operazioni aeroportuali. Posso dare un'occhiata alle issue aperte o al codice recente per capire perché gate, stand e check-in non vengono visualizzati nonostante l'aggiornamento.

Vuoi che controlli:

1. 🐛 Le issue aperte relative a gate/stand/check-in?
2. 📝 I commit recenti per vedere cosa è stato modificato?
3. 💻 Il codice direttamente per trovare dove vengono gestiti quei dati?

Dimmi come preferisci procedere! 🙂

User: Commit e codice

Assistant: Procedo a controllare entrambi contemporaneamente!

Assistant: Ora leggo i file chiave: staffMonitor.ts (il fetcher) e FlightScreen (dove vengono mostrate le pill).

Assistant: Ottimo, ho tutti i dettagli. Ecco l'analisi completa:

---

🔍 Analisi: perché stand/gate/check-in non vengono visualizzati

Cosa fa il codice (v1.3.4)

Il commit più recente (a6462e3) ha introdotto proprio questa funzionalità. Il flusso è:

1. staffMonitor.ts fa una fetch ogni 60 secondi verso:

   https://servizi.pisa-airport.com/staffMonitor/staffMonitor?trans=true&nature=D (o A)
   

2. Parsa l'HTML cercando righe <tr> con celle class="clsFlight".
3. I dati (stand, gate, checkin) vengono mostrati in FlightScreen.tsx come pill arancioni sotto ogni card, solo se il match per numero di volo riesce.

---

🐛 Le cause probabili per cui non vedi nulla

1. ⚠️ Il match del numero di volo fallisce silenziosamente

Il codice normalizza il numero di volo (es. FR07146 → FR7146) e poi cerca una corrispondenza esatta:

staffMonitorDeps.find(sm => sm.flightNumber === normFn)

Se il formato del numero di volo restituito dallo staffMonitor non corrisponde esattamente a quello di FR24, la pill non appare. Non c'è nessun log di errore visibile.

2. ⚠️ La fetch dello staffMonitor fallisce silenziosamente

In staffMonitor.ts il blocco catch ritorna semplicemente []:

} catch {
  return [];
}

Se la chiamata HTTP fallisce (CORS, rete, URL errato, ecc.) non viene registrato nessun errore, e staffMonitorDeps/staffMonitorArrs rim...

This pull request was created from Copilot chat.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
flight-work-app	Ready	Preview, Comment, Open in v0	Apr 6, 2026 9:32pm

[Copilot]

Pull request overview

This PR restores visibility of the staffMonitor-derived stand/gate/check-in/belt “pills” by making the staffMonitor fetch/parsing more resilient and improving flight-number matching in FlightScreen.

Changes:

• Add HTTP error logging + exception logging and dev-only parse diagnostics to fetchStaffMonitorData.
• Make the HTML row filter more permissive for detecting clsFlight rows.
• Add a fuzzy fallback flight-number match when exact matching fails.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
src/utils/staffMonitor.ts	Adds logging, relaxes row detection regex, and adds dev-only parse summary logging to improve reliability/diagnostics.
src/screens/FlightScreen.tsx	Adds fallback matching logic (stripped/uppercased) and dev-only “no match” logging to improve pill hit-rate.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

fetchStaffMonitorData is polled every 60s (see FlightScreen effect), so logging on every non-2xx response can spam production device logs when the endpoint is down. Consider gating this warning behind __DEV__, or rate-limiting/deduping (e.g., log only on status change / first failure within a window).

[Copilot]

Because this function runs on a 60s interval, emitting console.error on every exception can produce a large volume of logs in production during outages/parsing changes. Consider __DEV__-gating, rate-limiting, or tracking last-error time/message to avoid repeated identical logs.

[Copilot]

renderFlight now does up to two linear scans of smPool per rendered item. With a non-trivial number of flights this becomes O(renderedFlights × staffMonitorFlights) work during renders. Consider precomputing a lookup map (exact and stripped keys) with useMemo when staffMonitorDeps/Arrs changes, and then doing O(1) lookups inside renderFlight.