Audit de la santé des sources du data warehouse

Cette skill produit un audit à l'échelle du projet du côté source et synchronisation du pipeline du data warehouse — connexions de source, schémas de synchronisation et canaux de push webhook. Utilisez-la quand l'utilisateur souhaite un résumé de ce qui est cassé dans ses imports, et non une analyse approfondie d'une synchronisation. L'analyse approfondie des défaillances individuelles est gérée par diagnosing-failed-warehouse-syncs ; cette skill est l'analyse qui leur dit où chercher en premier.

Le même endpoint sous-jacent (data-warehouse-data-health-issues-retrieve) rapporte aussi les problèmes de materialized-view, de batch-export-destination et de transformation. Les vues matérialisées sont couvertes par auditing-warehouse-view-health. Les destinations (batch exports) et les transformations sont gérées par d'autres produits — signalez-les si elles apparaissent, mais renvoyez-les à l'équipe concernée plutôt que de les diagnostiquer ici.

Quand utiliser cette skill

• "Pourquoi mes imports échouent ?" / "Qu'est-ce qui est cassé avec mes sources ?"
• "Pourquoi mes données du warehouse sont obsolètes ?"
• L'utilisateur découvre un projet et veut savoir quelles sources il a hérité et si elles sont saines
• Examen hebdomadaire ou mensuel de la santé des sources/syncs
• Les tableaux de bord sont obsolètes et l'utilisateur ne sait pas quelle source est en cause

Outils disponibles

L'endpoint data-health-issues agrège tout le pipeline — c'est le chemin le plus rapide vers un résumé. Filtrez ses résultats par types source et external_data_sync pour cet audit. Utilisez les endpoints list quand vous avez besoin de plus de contexte que ce que le résumé fournit (comptages de lignes, éléments non défaillants, détail au niveau des schémas).

Ce qui compte comme un problème de source/sync

De l'endpoint data-health, cet audit porte sur deux des cinq catégories :

Chaque entrée inclut id, name, type, status, error, failed_at, url et source_type.

Les autres catégories que l'endpoint retourne sont hors de portée pour cette skill :

• materialized_view → auditing-warehouse-view-health
• destination (batch export) → gérée par le produit batch exports / data pipelines
• transformation (HogFunction) → gérée par le côté CDP / ingestion

Notez que l'endpoint data-health rapporte uniquement les défaillances actives. Pour la santé source/sync, il ne signale pas :

• Les schémas mis en pause par l'utilisateur (should_sync = false)
• Les schémas lents ou obsolètes mais techniquement Completed
• Les problèmes de webhook sur les schémas sync_type: "webhook". Le filet de sécurité bulk-sync peut réussir tandis que le canal de push webhook est silencieusement cassé (non enregistré, désactivé côté distant, validation de signature défaillante). Ces éléments ne remontent pas dans data-health-issues — vérifiez par source avec webhook-info-retrieve.

Si l'utilisateur demande des informations sur l'obsolescence ou les éléments inutilisés, allez au-delà de cet endpoint — voir Étape 4.

Flux de travail

Étape 1 — Snapshot unique

Appelez data-warehouse-data-health-issues-retrieve et conservez les entrées source et external_data_sync.

S'il n'y a pas de problèmes source/sync, dites à l'utilisateur que ses sources sont saines et arrêtez-vous. N'inventez pas de problèmes.

Étape 2 — Grouper et prioriser

1. Sources en Error d'abord. Une défaillance source cascade — chaque schéma sous elle est effectivement mort jusqu'à la reconnexion de la source. Résolvez ces problèmes en premier.
2. Schémas de synchronisation ensuite, dans cet ordre :
   • entrées status: "billing_limit" (problème de facturation, non technique — signalez et renvoyez à la facturation)
   • Failed sur des tables beaucoup utilisées (demande de l'utilisateur / vérifiez les comptages de lignes via schemas-list si nécessaire)
   • Failed sur des tables moins utilisées

Étape 3 — Présenter l'audit

Rendez un rapport priorisé. Ne videz pas le JSON brut — tableau lisible par catégorie :

## Santé des sources du data warehouse — 4 problèmes

### 🔴 Sources (1)
- Stripe — authentification échouée (défaillance il y a 2h). Les 8 tables sous elle sont actuellement mortes.
  → `diagnosing-failed-warehouse-syncs` sur cette source

### 🟠 Schémas de synchronisation (3)
- postgres_prod.orders (Défaillance il y a 6h) — colonne "updated_at" n'existe pas
- postgres_prod.invoices (Défaillance il y a 6h) — colonne "updated_at" n'existe pas
- hubspot.contacts (BillingLimitReached) — quota d'équipe dépassé

Ordre recommandé :
1. Auth Stripe (tout ce qui est dessous est mort)
2. Schema-drift sur postgres_prod.orders / invoices — ressemble à un renommage de colonne en amont
3. Limite de facturation sur hubspot

Le format exact importe moins que : priorisé, groupé, actionnable et suggérant la bonne skill suivante.

Étape 4 — Aller au-delà des défaillances actives (sur demande)

Si l'utilisateur en veut plus que juste "ce qui brûle" — par ex. "qu'est-ce d'autre je devrais regarder ?" — vérifiez en croisé :

Schémas obsolètes mais "Completed" : Appelez external-data-schemas-list et cherchez les schémas avec last_synced_at ancien relatif à leur sync_frequency. Un schéma en 1hour qui a synchronisé pour la dernière fois il y a 3 jours est effectivement cassé même si le statut dit Completed.

Sources sans activité de synchronisation : Sources où chaque schéma a should_sync: false ou status = Paused. Elles ont été configurées puis abandonnées — candidates pour nettoyage via external-data-sources-destroy.

Webhooks cassés sur schémas webhook : Parcourez les sources qui ont au moins un schéma avec sync_type: "webhook" (visible via external-data-schemas-list). Pour chacune, appelez external-data-sources-webhook-info-retrieve({source_id}) :

• exists: false tandis qu'un schéma est sync_type: "webhook" → webhook n'a jamais été enregistré, ou a été supprimé. Le canal de push est mort ; seul le fallback bulk ingère les données.
• external_status.error présent → le service distant signale un problème (permission révoquée, endpoint supprimé sur leur dashboard).
• external_status.status pas "enabled" → le distant a désactivé l'endpoint (souvent après défaillances de livraison répétées).

Signalez ces éléments séparément de l'audit principal — ce sont une forme différente de problème que les syncs défaillants, et la correction est une skill différente (diagnosing-failed-warehouse-syncs scénario I, ou setting-up-a-data-warehouse-source étape 5.5).

Exécutez ces vérifications supplémentaires uniquement si l'utilisateur demande explicitement un audit plus large — elles impliquent plus d'appels d'outils et d'heuristiques.

Étape 5 — Proposer l'étape suivante

Terminez l'audit avec un transfert clair :

• "Veux-tu que je creuse la défaillance Stripe ?" → transfert à diagnosing-failed-warehouse-syncs
• "Veux-tu que je corrige le schema drift sur orders ?" → transfert à tuning-incremental-sync-config
• "Veux-tu désactiver les schémas limités par facturation ?" → one-click via external-data-schemas-partial-update

Ne commencez jamais à appliquer des corrections de manière autonome depuis le flux d'audit — le travail de l'audit est de rapporter et recommander, non de corriger. Toute correction doit être confirmée explicitement avant d'être exécutée.

Notes importantes

• L'audit est en lecture seule. N'appelez jamais les outils destructifs depuis le flux d'audit. Transférez vers les skills de diagnostic/tuning — lesquelles à leur tour confirment avant d'agir.
• Vide = sain. Ne remplissez pas un audit vide avec des problèmes hypothétiques. "Aucun problème de source trouvé" est une bonne réponse.
• Les défaillances de source cascadent. Quand vous rapportez une source en Error, mentionnez aussi quels schémas sous elle sont affectés (ou seront affectés, une fois qu'ils essaient de synchroniser à nouveau). L'utilisateur doit comprendre le rayon de blast.
• Les limites de facturation ne sont pas des problèmes techniques. Signalez-les mais renvoyez à la facturation / discussion de quota, pas à une action de récupération.
• data-health-issues rapporte uniquement les défaillances actives. Pour l'obsolescence ou les sources abandonnées, vous devez vérifier en croisé les endpoints list. Ne faites cela que quand l'utilisateur demande explicitement un audit plus profond.
• La santé webhook est séparée de la santé des schémas. L'endpoint data-health ne connaît pas l'état webhook. Quand la demande d'un utilisateur mentionne "temps réel", "webhook Stripe", ou "pourquoi les données ont-elles des heures de retard sur une source webhook", allez directement à webhook-info-retrieve plutôt que d'inférer du statut du schéma.
• Les vues matérialisées, destinations et transformations sont hors de portée ici. Elles partagent l'endpoint data-health mais appartiennent à d'autres audits/produits — renvoyez, ne diagnostiquez pas.