Dry run joué : 20 sections orphelines, et une décision produit en attente
Recette d'import documentée (MigrationController lit un Mongo vivant, pas les fichiers de migration-data/), résultats des comptages, et les deux réserves : l'export a 4 mois alors que la prod tourne encore sur Mongo, et les 20 sections orphelines sont du contenu MDLF réel dont le sort doit être tranché avec le client — recréer les 2 configurations, ou acter la perte. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Thomas Fransolet
parent
1321f0cebe
commit
526bb904b1
@ -308,13 +308,15 @@ Les lots 1 et 2 sont terminés. **Le lot 3 et le lot médias sont tous les deux
|
||||
|
||||
**Chemin critique** : A (assainir) → B (geler le schéma) → G (`MigrationController`) → H (tests) → **J (RGPD)** → I (bascule). C, D, D-bis, E, F se parallélisent.
|
||||
|
||||
**Lot G — les 8 écarts sont clos le 2026-08-11. Reste le dry run.** `dotnet build` vert, `dotnet test` **143/143**.
|
||||
**Lot G — les 8 écarts sont clos et le dry run est joué (2026-08-11).** `dotnet build` vert, `dotnet test` **143/143**.
|
||||
|
||||
**Trois des huit n'existaient pas.** Le plan les décrivait en « perte de données » ; l'export Mongo dit qu'il n'y a rien à perdre :
|
||||
- **(a)** `BuildSection` couvre exactement les types présents : les 327 sections de l'export ne contiennent que les valeurs 0 à 10. `SectionEvent` et `SectionParcours` sont nés avec Postgres v3.
|
||||
- **(f)** `IsQRCode`/`IsSearchText`/`IsSearchNumber` n'existent pas dans Mongo — `false` est le bon défaut. Contrôle inverse fait : les cinq réglages qui *existent* (`IsDate`, `IsHour`, `IsSectionImageBackground`, `RoundedValue`, `ScreenPercentageSectionsMainPage`) sont bien mappés sur `AppConfigurationLink`.
|
||||
- **(g)** tombé avec le rename du lot B.
|
||||
|
||||
**Dry run** : automatisé en test (`MigrationDryRunTests`, se saute sans Mongo), joué sur l'export du 1ᵉʳ avril. Il a trouvé du premier coup **20 sections manquantes avec `Erreurs : 0`** — elles référencent 2 configurations supprimées dans Mongo (contenu MDLF). Pas un défaut de migration, mais un silence : elles sont désormais signalées dans `Skipped`. ⚠️ **Décision produit en attente** : recréer les 2 configurations avant la bascule pour récupérer ce contenu, ou acter sa perte. ⚠️ **À rejouer sur un dump frais** avant le jour J — l'export a 4 mois et la prod tourne encore sur Mongo.
|
||||
|
||||
**Les cinq vrais, corrigés** :
|
||||
- **(b)** mesuré : **5 sections quiz portent 41 questions**, toutes jetées. Migrées avec leurs réponses, en `MultipleChoice` (le type de validation n'existait pas dans l'ancien modèle). Les agendas n'ont aucun événement dans Mongo et les parcours n'y existent pas : leurs collections vides sont correctes.
|
||||
- **(c)** tout est généré ou dérivé, cf. v1-plan.
|
||||
|
||||
@ -827,7 +827,10 @@
|
||||
<article class="card" data-area="backend infra">
|
||||
<div class="card-meta"><span class="tag">étape 15</span><span class="flag f-good">Sans risque</span></div>
|
||||
<h3>Dry run + comparaison des comptages</h3>
|
||||
<p><code>dryRun=true</code> n'écrit rien. Rejouer sur l'export Mongo déjà présent dans <code>manager-service/migration-data/</code> et comparer entité par entité aux comptages Mongo. C'est ce qui révèle les quatre cartes ci-dessus sur des données réelles plutôt que par lecture de code.</p>
|
||||
<p><code>dryRun=true</code> n'écrit rien. <strong>🔨 Joué le 11/08</strong> sur l'export du 1ᵉʳ avril, et automatisé en test (<code>MigrationDryRunTests</code>, qui se saute si aucun Mongo n'écoute — la suite reste verte sans dépendance).</p>
|
||||
<p><strong>Il a trouvé du premier coup ce qu'aucune lecture de code n'avait vu</strong> : 327 sections dans Mongo, <strong>307 migrées, et <code>Erreurs : 0</code></strong>. Les 20 manquantes référencent deux configurations <em>supprimées</em> dans Mongo — 19 articles et un slider, du contenu MDLF bien réel (« Senteur : fraises », « Pupitre vigne », « Ruche 7 »). Ce n'est pas un défaut de la migration : les sections sont collectées configuration par configuration, donc les orphelines n'étaient jamais énumérées. <strong>Le défaut était le silence</strong> — elles partent maintenant dans <code>Skipped</code>, et le test affirme <code>migrées + signalées = Mongo</code>.</p>
|
||||
<p>⚠️ <strong>Décision produit</strong> : recréer les 2 configurations dans Mongo avant la bascule pour récupérer ces 20 sections, ou acter leur perte. À trancher avec MDLF.</p>
|
||||
<p>⚠️ <strong>À rejouer sur un dump frais</strong> : l'export a 4 mois et la prod tourne encore sur Mongo. Et <code>MigrationController</code> lit un Mongo <em>vivant</em>, pas ces fichiers — recette d'import dans v1-plan.</p>
|
||||
<span class="src">STATUS.md §1quinquies — étape 15</span>
|
||||
</article>
|
||||
|
||||
|
||||
33
v1-plan.md
33
v1-plan.md
@ -197,7 +197,38 @@ Les 8 écarts a→h du §1quinquies. Ne démarre qu'après les lots B et C1 (**L
|
||||
| g | `MapResourceId = dto?.iconResourceId` | **L6** — tombe avec le lot B |
|
||||
| ~~h~~ ✅ **2026-08-11** | Pas de transaction globale, `catch` qui renvoie 200 OK | Transaction unique sur les neuf étapes : soit tout est là, soit rien. Et l'échec fatal renvoie désormais **500** — le piège était qu'un script de bascule testant le code HTTP concluait au succès, l'erreur n'étant que dans le corps. En `dryRun`, pas de transaction ouverte : rien n'est écrit |
|
||||
|
||||
Puis : **dry run** (`dryRun=true`) sur l'export Mongo de `manager-service/migration-data/`, et **comparaison des comptages par entité** avec Mongo. C'est la seule preuve que les écarts a, b et c sont fermés.
|
||||
Puis : **dry run** (`dryRun=true`) et **comparaison des comptages par entité**. C'est la seule preuve que les écarts sont fermés.
|
||||
|
||||
🔨 **Joué le 2026-08-11 sur l'export du 1ᵉʳ avril.** Automatisé en test (`MigrationDryRunTests`), qui **se saute si aucun Mongo n'écoute** sur `MIGRATION_TEST_MONGO` (défaut `mongodb://localhost:27018`) — la suite reste donc verte sans dépendance. `dotnet test` **144/144**.
|
||||
|
||||
⚠️ **`MigrationController` lit un MongoDB vivant, pas les fichiers de `migration-data/`.** Ces JSON sont un export : il faut les importer dans un Mongo avant tout dry run. Recette (rien à installer sur l'hôte) :
|
||||
|
||||
```bash
|
||||
docker run -d --name myim_mongo_dryrun -p 27018:27017 mongo:6
|
||||
# monter ailleurs que sous /data : l'image mongo y déclare déjà des volumes
|
||||
for c in Instances Users Configurations Resources Sections Devices; do
|
||||
docker run --rm --network container:myim_mongo_dryrun -v "$PWD/migration-data:/import:ro" mongo:6 mongoimport --uri mongodb://localhost:27017 --db TabletDb --collection $c --file /import/TabletDb.$c.json --jsonArray --drop
|
||||
done
|
||||
dotnet test --filter MigrationDryRunTests
|
||||
```
|
||||
|
||||
**Résultat, et ce qu'il a trouvé du premier coup :**
|
||||
|
||||
| Entité | Mongo | Migré |
|
||||
|---|---|---|
|
||||
| Instances | 4 | 4 |
|
||||
| Users | 10 | 10 |
|
||||
| Configurations | 15 | 15 |
|
||||
| Resources | 2374 | 2374 |
|
||||
| **Sections** | **327** | **307** + 20 signalées |
|
||||
| Devices | 46 | 46 |
|
||||
|
||||
**20 sections manquaient, avec `Erreurs : 0`** — la perte silencieuse même. Diagnostic : elles référencent **deux configurations qui n'existent plus** dans Mongo (`6863c9af…`, `6863cac9…`) — 19 articles et un slider, du contenu MDLF (« Senteur : fraises », « Pupitre vigne », « Ruche 7 »). Ce n'est **pas un défaut de la migration** : les sections sont collectées configuration par configuration, donc les orphelines n'étaient jamais énumérées, et la FK `ConfigurationId` les refuserait de toute façon. Le défaut était le **silence**. Elles partent désormais dans `Skipped`, et le test affirme l'invariant qui compte : `migrées + signalées = Mongo`.
|
||||
|
||||
> ⚠️ **Décision produit en attente** : ces 20 sections sont du contenu réel qui n'arrivera pas en Postgres. Soit on recrée les 2 configurations manquantes dans Mongo **avant** la bascule pour les récupérer, soit on acte leur perte. À trancher avec MDLF, pas en interne.
|
||||
|
||||
⚠️ **L'export date du 1ᵉʳ avril, la prod tourne encore sur Mongo** : ce dry run valide la mécanique, pas les comptages du jour J. **À rejouer sur un `mongodump` frais** juste avant la bascule — de préférence avec un utilisateur Mongo `readAnyDatabase` créé pour l'occasion, plutôt qu'en pointant l'app de dev sur la prod : les six `DatabaseService` exposent `InsertOne`/`ReplaceOne`/`DeleteOne`, et `dryRun` ne protège que Postgres.
|
||||
|
||||
|
||||
### Lot H — Tests end-to-end (1 semaine)
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user