Files
games/docs/development/003-TRACING_AND_DIAGNOSTICS.md
2026-09-20 13:58:13 +02:00

1.7 KiB
Raw Blame History

Tracing et diagnostics

Objectif

Le projet utilise tracing comme façade structurée commune pour les événements de diagnostic Rust. Les applications choisissent le subscriber adapté à leur distribution ; les librairies émettent des événements sans imposer une destination globale.

Socle initial

crates/common/game-logging-lib regroupe linitialisation réutilisable. La première implémentation fournit :

  • un subscriber console formaté ;
  • une écriture non bloquante via tracing-appender ;
  • un guard dont la durée de vie protège le flush des événements ;
  • un subscriber local destiné aux tests.

Les runners Desktop initialisent ce socle. Les futures intégrations Android pourront adapter la destination aux contraintes Logcat/plateforme sans modifier les crates jeu.

Évolution

Les filtres par target/niveau, fichiers rotatifs, configuration utilisateur, traces Android et éventuelle télémétrie distante seront ajoutés uniquement lorsquun besoin concret les justifie.

Host navigateur direct

Le navigateur direct ne possède ni backend Rust Tauri ni plugin de relayage. Son frontend utilise donc un module TypeScript unique de diagnostics structurés qui écrit dans la console du navigateur avec target, action et champs associés. Les modules applicatifs n'émettent pas leurs propres formats parallèles.

Cette sortie console est un mécanisme frontend. Elle ne remplace pas tracing dans le code Rust : les runners natifs continuent d'initialiser game-logging-lib, et un futur besoin de tracing Rust directement dans WebAssembly devra être introduit explicitement plutôt que d'être simulé par le frontend.