Troubleshooting fuer Message Popups
Warum ist Payload-Inhalt maskiert?
Payload-Masking ist meist kein zufaelliger UI-Fehler, sondern ein bewusstes Permission-Ergebnis.
Pruefe diese Kette:
- darf der Benutzer den Flow ueberhaupt sehen
- ist der Flow fuer die Ressource
payloadsblockiert - enthaelt die Antwort
masked: true - enthaelt die Antwort
restricted_resources: ["payloads"]
Wenn das alles zutrifft, arbeitet das System wie vorgesehen.
Warum werden Custom Header durch *** ersetzt?
Das passiert, wenn der Benutzer die Message-Zeile sehen darf, der Flow aber fuer custom_headers blockiert ist.
Typisches Detail-Ergebnis:
- Message bleibt sichtbar
- Header-Namen koennen sichtbar bleiben
- Header-Werte werden durch
***ersetzt restricted_resourcesenthaeltcustom_headers
Warum sehe ich Payload-Zeilen, kann aber keinen Payload herunterladen?
Das sind zwei unterschiedliche Permission-Ebenen:
- Payload-Metadaten koennen weiter in maskierter Form sichtbar sein
- Raw-Payload-Download wird ueber den Download-Endpunkt verweigert
Der typische Blockierungsweg im Backend ist:
- Flow fuer Metadaten noch sichtbar
- Payload-Ressource eingeschraenkt
- Download-Endpunkt wirft
PermissionDenied
Warum sind Message-Details veraltet, obwohl der Tenant aktiv ist?
Das Message-Popup liest synchronisierte Monitoring-Daten und nicht garantiert einen Live-CPI-Zustand.
Pruefe:
jobs.messages.config.enabledlast_run_hotlast_run_cold- ob die Message-Schleife noch auf Packages wartet
- ob Hot- oder Cold-Sync-Taktung zu deiner Erwartung passt
Siehe Worker Runtime Troubleshooting.
Warum fehlen Correlations oder Runs?
Moegliche Erklaerungen:
- Correlation-Count ist nur
0oder1 - korrelierte Messages werden durch Scope gefiltert
- Runs wurden fuer diese Message noch nicht persistiert
- die Message-Zeile existiert bereits, aber ihre tieferen Laufzeitobjekte sind noch unvollstaendig
Typische Feldhinweise
| Feld | Diagnosehinweis |
|---|---|
payloads_count = 0 | noch keine persistierten Payload-Zeilen |
runs_count = 1 | nur ein Run bekannt oder gespeichert |
customheaders_count = 0 | keine gespeicherten Custom Header |
correlation_ncount <= 1 | kein relevanter Correlation-Verbund |
restricted_resources nicht leer | permission-basiertes Masking ist aktiv |
Warum passt das Popup nicht zum Alert-Verhalten?
Popup und Alerting gehoeren zusammen, sind aber nicht dasselbe:
- das Popup ist die Inspektionsschicht
- Alerting ist die Auswertungsschicht auf Basis gespeicherter Laufzeitdaten
Darum koennen sichtbare fehlgeschlagene Messages existieren, obwohl kein Message-Alert sichtbar ist, wenn:
- Alert-Definitionen fachlich nicht auf diese Messages passen
- Suppression- oder Outdated-Logik die Sicht geaendert hat
- der Alert-Loop zeitlich hinter dem Message-Sync liegt