146 lines
5.7 KiB
Markdown
146 lines
5.7 KiB
Markdown
<!-- file: deltas/0.1.4/pre.016.md -->
|
|
<!-- version: 1 -->
|
|
|
|
# Delta `0.1.4-pre.016` — Logging runtime : identité de lancement et profil actif
|
|
|
|
## Base
|
|
|
|
`0.1.4-pre.015-fix.003` est validée : `cargo fmt --all`, `cargo check --workspace`, `cargo clippy --workspace --all-targets`, 51 tests `ksp-app-config-desk`, 88 tests `ksp-config-lib`, 5 audits ownership et 12 tests d'API publique passent. Le hot reload persistence + runtime de `pre.015` a également été validé avec `runtime_applied=true` et une génération qui avance sans redémarrage.
|
|
|
|
## Objectif
|
|
|
|
Compléter le runtime Logging sans déplacer l'ownership :
|
|
|
|
- `ksp-logging-lib` reste seul propriétaire du subscriber et des sinks ;
|
|
- `ksp-config-lib` reste seul propriétaire du document Logging et de sa résolution ;
|
|
- Config Desk compose ces contrats et expose leur état.
|
|
|
|
Cette tranche ne crée pas encore le panneau manuel **Test Logging** prévu en `pre.017`.
|
|
|
|
## Changements
|
|
|
|
### Identité stable par lancement
|
|
|
|
`ksp-logging-lib` ajoute `LoggingRuntimeIdentity` et `initialize_with_identity()`.
|
|
|
|
L'identité contient :
|
|
|
|
- un `application_id` ;
|
|
- un token `launch_timestamp` construit une seule fois par l'application.
|
|
|
|
Config Desk utilise un token UTC de la forme :
|
|
|
|
```text
|
|
20260816-182519.123Z-p4242
|
|
```
|
|
|
|
Chaque file sink actif reçoit un prefix effectif de la forme :
|
|
|
|
```text
|
|
<application_id>.<launch_timestamp>.<configured_file_name_prefix>
|
|
```
|
|
|
|
Exemple :
|
|
|
|
```text
|
|
ksp-app-config-desk.20260816-182519.123Z-p4242.ksp-debug.log
|
|
```
|
|
|
|
Le `FileSettings` source n'est pas muté. `reinitialize()` réutilise automatiquement l'identité conservée dans `LoggingGuard`, donc tous les hot reloads d'un même processus gardent le même prefix de lancement. Un nouveau lancement produit une nouvelle identité et ne fusionne plus ses fichiers avec le précédent, même avec une rotation `daily`.
|
|
|
|
`LoggingGuard::active_file_outputs()` expose des `RuntimeFileMetadata` sûres : `output_id`, directory résolu, prefix effectif et rotation.
|
|
|
|
### Runtime Logging observable
|
|
|
|
Config Desk ajoute :
|
|
|
|
- `LoggingRuntimeStatusDto` ;
|
|
- `LoggingRuntimeFileDto` ;
|
|
- `get_logging_runtime_status`.
|
|
|
|
La vue Logging affiche maintenant :
|
|
|
|
- profil runtime actif ;
|
|
- source de sélection (`default_profile`, `explicit`, `fallback`) ;
|
|
- génération ;
|
|
- état console ;
|
|
- fallback ;
|
|
- dropped lines console/fichiers/total ;
|
|
- application id ;
|
|
- launch timestamp ;
|
|
- file sinks actifs et leur prefix effectif.
|
|
|
|
L'overview est rafraîchi après un changement runtime afin de refléter immédiatement `active_logging_profile` et `logging_generation`.
|
|
|
|
### Profil runtime explicite
|
|
|
|
Config Desk ajoute `apply_logging_profile`.
|
|
|
|
Cette commande :
|
|
|
|
1. recharge un `ConfigEnvironment` frais ;
|
|
2. résout un profil **déjà persisté** avec `load_resolved_logging_config(Some(profile_id), ...)` ;
|
|
3. prépare et applique le runtime via `ksp_logging_lib::reinitialize()` ;
|
|
4. avance la génération uniquement après succès ;
|
|
5. marque `selection_source=explicit` ;
|
|
6. ne modifie ni `default_profile` ni le document source.
|
|
|
|
Le frontend interdit l'application explicite lorsque le brouillon est sale, afin de ne pas confondre un profil local non persisté avec un profil réellement résolu par Config.
|
|
|
|
Une future action **Sauvegarder et appliquer** continue au contraire d'appliquer le `default_profile` persisté et marque `selection_source=default_profile`.
|
|
|
|
### Rollback/runtime
|
|
|
|
Les garanties existantes sont conservées :
|
|
|
|
- `reinitialize()` prépare les nouveaux sinks/layers avant le swap ;
|
|
- en cas d'échec, le runtime précédent reste actif ;
|
|
- pour une sauvegarde de document suivie d'un échec runtime, Config Desk restaure la source précédente ;
|
|
- une application explicite de profil n'écrit aucune source, donc un échec ne peut pas altérer le document.
|
|
|
|
### Tests
|
|
|
|
Les tests ajoutés couvrent notamment :
|
|
|
|
- validation de l'identité de lancement ;
|
|
- rejet des composants contenant paths/espaces ;
|
|
- projection des rotations et compteurs runtime ;
|
|
- décoration des prefixes sans mutation des `FileSettings` ;
|
|
- maintien de l'identité dans le test d'intégration global à travers les hot reloads et plusieurs file sinks ;
|
|
- adressabilité de la nouvelle API publique Logging.
|
|
|
|
## Version technique
|
|
|
|
```text
|
|
workspace.package.version = 0.1.4-pre.16
|
|
```
|
|
|
|
Une dépendance workspace `time ^0.3` avec feature `std` est ajoutée uniquement pour construire le token UTC lisible de lancement dans Config Desk.
|
|
|
|
## Validation attendue
|
|
|
|
```bash
|
|
cargo fmt --all
|
|
cargo check --workspace
|
|
cargo clippy --workspace --all-targets
|
|
cargo test -p ksp-app-config-desk
|
|
cargo test -p ksp-config-lib
|
|
cargo test -p ksp-logging-lib
|
|
cargo tree -p ksp-app-config-desk
|
|
cargo tauri dev -c crates/ksp-app-config-desk/tauri.conf.json
|
|
```
|
|
|
|
Contrôles fonctionnels :
|
|
|
|
1. noter `application_id`, `launch_timestamp` et les prefixes fichiers dans **Runtime actif** ;
|
|
2. effectuer plusieurs hot reloads et vérifier que `launch_timestamp`/prefixes restent identiques tandis que `generation` avance ;
|
|
3. redémarrer réellement l'application et vérifier qu'un nouveau `launch_timestamp`/prefix est créé ;
|
|
4. persister au moins deux profils, laisser `default_profile=A`, puis appliquer explicitement `B` ;
|
|
5. vérifier `active_profile=B`, `selection_source=explicit`, génération avancée et `default_profile=A` inchangé après rechargement du document ;
|
|
6. sauvegarder/appliquer le document et vérifier que le runtime revient au `default_profile` avec `selection_source=default_profile` ;
|
|
7. vérifier sur disque que deux lancements distincts n'écrivent pas dans le même fichier persistant.
|
|
|
|
## Suite
|
|
|
|
`0.1.4-pre.017` ajoute le panneau **Test Logging** : message, niveaux, target contrôlé, domain et preuves de routing avant/après hot reload et via le bridge frontend.
|