Buero-Visualisierung: Render-Fehler nach erfolgreichem Live-Fetch nicht mehr als "API nicht erreichbar" melden

refresh() zeigte den roten Banner bisher fuer jeden Fehler im gesamten try-Block, auch wenn
loadLiveData() laengst erfolgreich war und erst das anschliessende Verarbeiten/Zeichnen der
Live-Daten scheiterte (Issue #94: Produktion meldete "API nicht erreichbar", obwohl ein
direkter curl-Aufruf die API nachweislich erreichte). Jetzt entscheidet ausschliesslich der
Erfolg von loadLiveData() ueber Banner/Demo-Fallback; ein spaeterer Fehler beim Verarbeiten
wird nur noch geloggt, ohne die Erreichbarkeit faelschlich zu verneinen.

Getestet: composer test (262 Tests) und npm test/frontend (98 Tests) in Docker, beide gruen.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
fds2610-bot 2026-09-23 08:48:58 +02:00
parent 18990c2d80
commit a93c940680

View file

@ -2626,9 +2626,34 @@ async function boot() {
} }
async function refresh() { async function refresh() {
// Issue #94, zweiter Anlauf: der erste Fix (siehe Kommentar unten bei renderOfficeScene())
// sorgte zwar dafuer, dass der Banner ueberhaupt erscheint, hat aber "API nicht erreichbar"
// faelschlich auch dann gezeigt, wenn loadLiveData() laengst erfolgreich war und erst das
// anschliessende Verarbeiten/Zeichnen der Live-Daten scheiterte - Produktion meldete dann
// trotz per curl nachweislich erreichbarer API weiterhin Unerreichbarkeit. Deshalb jetzt
// zwei getrennte try-Bloecke: nur ein Fehlschlag von loadLiveData() selbst ist ein
// Erreichbarkeitsproblem und darf den Demo-Fallback samt Banner ausloesen.
let data;
try {
data = await loadLiveData();
} catch (err) {
console.warn("[office] Live-API nicht erreichbar, zeige Demo-Daten.", err);
// setApiBanner() steht in einem eigenen finally: renderOfficeScene() zeichnet bei jedem
// Refresh die komplette Szene neu und kann durch einen Fehler in noch unbekannten
// Datenkombinationen scheitern (siehe Issue #94 - Produktion zeigte trotz nicht
// erreichbarer API keinen Banner). Ohne das finally wuerde ein solcher Fehler die
// wichtigere Meldung "API nicht erreichbar" mit sich reissen, statt sie anzuzeigen.
try {
renderOfficeScene(container);
} finally {
setApiBanner(true);
}
return;
}
setApiBanner(false);
lastLiveData = data;
try { try {
const data = await loadLiveData();
lastLiveData = data;
if (previousTickets) { if (previousTickets) {
const previousById = new Map(previousTickets.map((ticket) => [ticket.id, ticket])); const previousById = new Map(previousTickets.map((ticket) => [ticket.id, ticket]));
@ -2684,19 +2709,12 @@ async function boot() {
resolvePendingAgentTicketMoves(data.agents); resolvePendingAgentTicketMoves(data.agents);
previousTickets = data.tickets; previousTickets = data.tickets;
renderLiveScene(data); renderLiveScene(data);
setApiBanner(false);
} catch (err) { } catch (err) {
console.warn("[office] Live-API nicht erreichbar, zeige Demo-Daten.", err); // Die API war erreichbar (loadLiveData() oben ist bereits durchgelaufen) - ein Fehler
// setApiBanner() steht in einem eigenen finally: renderOfficeScene() zeichnet bei jedem // hier ist ein Render-/Verarbeitungsbug, kein Erreichbarkeitsproblem. Der Banner bleibt
// Refresh die komplette Szene neu und kann durch einen Fehler in noch unbekannten // deshalb aus (siehe setApiBanner(false) oben); der naechste Poll-Zyklus versucht es
// Datenkombinationen scheitern (siehe Issue #94 - Produktion zeigte trotz nicht // erneut, sobald startRealtimeUpdates() ihn ausloest.
// erreichbarer API keinen Banner). Ohne das finally wuerde ein solcher Fehler die console.error("[office] Fehler beim Verarbeiten/Zeichnen der Live-Daten.", err);
// wichtigere Meldung "API nicht erreichbar" mit sich reissen, statt sie anzuzeigen.
try {
renderOfficeScene(container);
} finally {
setApiBanner(true);
}
} }
} }