C2 — POST /api/Resource/backfill-storage, SuperAdmin, dryRun à true par
défaut : la migration se joue sur une base vide, ce backfill sur des lignes
de production. StoragePath par ResourceStorage.PathFor, SizeBytes par HEAD.
La méthode annoncée au plan — « SizeBytes par listing du bucket Firebase » —
était inapplicable : le serveur n'avait aucun client de stockage. Le sondage
passe donc par HEAD sur l'URL publique, comme le fait déjà la migration, et
le sondeur est extrait plutôt que recopié (Helpers/ResourceSizeProbe,
consommé par MigrationController et par le backfill). Même raisonnement que
pour ResourceStorage : deux copies auraient divergé sur ce qui compte, le
sort réservé aux échecs.
L'extraction a bouché un trou que personne ne cherchait. L'original ne notait
l'échec que dans son catch, or un HEAD sur un blob absent ne lève pas : il
répond 404, sans Content-Length. Ces ressources arrivaient à 0 octet sans
figurer dans le rapport — invisibles au quota et invisibles au diagnostic,
exactement ce que le commentaire d'origine voulait empêcher.
Le « 37 lignes sur 45 » du plan n'étant pas vérifiable, le backfill rend son
propre inventaire : Orphans (aucune URL, blob peut-être jamais téléversé) et
Unsized (URL présente, bucket muet) restent séparés, ce sont deux causes
distinctes.
C3 — pré-vol du quota sur les deux chemins de création, suppression du blob
à Delete, angle mort d'Update tranché.
Deux défauts trouvés en câblant, qui n'étaient documentés nulle part :
- Le pré-vol existait déjà à moitié. Upload (multipart) contrôlait et
renvoyait 413, Create (JSON) ne contrôlait rien — or c'est le chemin
qu'emprunte manager-app, qui crée la ligne puis téléverse.
- Les deux lectures du quota divergeaient. Upload lisait le quota du plan,
GetQuota celui de l'instance avec le plan en repli. Une instance à quota
surchargé — le mécanisme même de l'add-on — affichait un chiffre à l'écran
et se faisait bloquer sur un autre. Helpers/StorageQuota devient la seule
source de vérité pour les deux.
Delete supprime le blob AVANT la ligne et renvoie 502 en conservant la ligne
si le bucket échoue. manager-app faisait l'inverse en avalant l'échec dans un
print : la ligne disparaissait, le blob restait, et n'ayant plus de ligne il
devenait invisible au quota tout en restant facturé. Une ressource encore
listée se rattrape ; un blob que plus aucune ligne ne désigne, non.
L'angle mort laissé ouvert par C1 était une fausse crainte : PathFor ne
construit qu'un pictures/{instanceId}/{resourceId}, le type n'entre pas dans
le chemin, il décide seulement s'il y en a un. Recalculer ne peut donc pas
pointer ailleurs, et Update rejoue Apply.
Aucun secret nouveau : FirebaseAdmin était déjà référencé pour les
notifications push et Startup charge déjà un service account, donc
Google.Cloud.Storage.V1 réutilise le même GoogleCredential. Seule s'ajoute la
clé Firebase:StorageBucket, vide par défaut — à renseigner en prod (I9),
sans quoi Delete ne supprime rien et ne prétend pas le contraire.
dotnet build vert, dotnet test 163/163 (148 au départ, +7 pour C2, +8 pour C3).
Contient aussi le correctif d'indexation préparé en parallèle : un job
Hangfire par section dans BackfillInstanceAsync au lieu d'une boucle, et un
backoff sur 429/503 dans GoogleEmbeddingService.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
87 lines
3.7 KiB
C#
87 lines
3.7 KiB
C#
using System;
|
|
using System.Collections.Concurrent;
|
|
using System.Collections.Generic;
|
|
using System.Linq;
|
|
using System.Net.Http;
|
|
using System.Threading.Tasks;
|
|
|
|
namespace ManagerService.Helpers
|
|
{
|
|
/// <summary>
|
|
/// Sonde le poids d'un blob par requête HEAD sur son URL publique, par lots.
|
|
///
|
|
/// Deux appelants : <c>MigrationController</c> (écart e de la bascule) et le backfill
|
|
/// des lignes existantes. Comme <see cref="ResourceStorage"/>, c'est un calculateur
|
|
/// unique plutôt que deux implémentations qui divergeraient — ici sur la taille de lot,
|
|
/// le délai d'attente et surtout le sort réservé aux échecs.
|
|
///
|
|
/// ⚠️ Le serveur n'a aucun client de bucket : ni Firebase Admin ni Google.Cloud.Storage
|
|
/// ne sont référencés dans le projet, les blobs étant téléversés depuis manager-app
|
|
/// directement. L'URL publique est donc le seul moyen de connaître une taille.
|
|
/// </summary>
|
|
public static class ResourceSizeProbe
|
|
{
|
|
/// <summary>Trente requêtes en vol à la fois, valeur héritée de la migration.</summary>
|
|
public const int BatchSize = 30;
|
|
|
|
public sealed class Result
|
|
{
|
|
private readonly ConcurrentDictionary<string, long> _sizes = new();
|
|
private readonly ConcurrentDictionary<string, bool> _unsized = new();
|
|
|
|
public bool TryGetSize(string id, out long size) => _sizes.TryGetValue(id, out size);
|
|
|
|
/// <summary>
|
|
/// Vrai si la sonde n'a pas su donner de taille : HEAD en échec, ou réponse
|
|
/// sans <c>Content-Length</c>. Les deux cas laissent la ressource à 0 octet,
|
|
/// donc invisible au quota — l'appelant doit le signaler, pas l'avaler.
|
|
/// </summary>
|
|
public bool IsUnsized(string id) => _unsized.ContainsKey(id);
|
|
|
|
public int SizedCount => _sizes.Count;
|
|
public int UnsizedCount => _unsized.Count;
|
|
|
|
internal void Record(string id, long size) => _sizes[id] = size;
|
|
internal void RecordUnsized(string id) => _unsized[id] = true;
|
|
}
|
|
|
|
/// <summary>
|
|
/// Le <paramref name="client"/> est fourni par l'appelant, qui reste maître du
|
|
/// délai d'attente : la migration accepte 10 s par ressource, un backfill lancé
|
|
/// à la main peut vouloir plus.
|
|
/// </summary>
|
|
public static async Task<Result> ProbeAsync(HttpClient client, IEnumerable<(string Id, string Url)> targets)
|
|
{
|
|
var result = new Result();
|
|
var list = targets.Where(t => !string.IsNullOrEmpty(t.Url)).ToList();
|
|
|
|
for (int i = 0; i < list.Count; i += BatchSize)
|
|
{
|
|
var batch = list.Skip(i).Take(BatchSize);
|
|
await Task.WhenAll(batch.Select(async target =>
|
|
{
|
|
try
|
|
{
|
|
var request = new HttpRequestMessage(HttpMethod.Head, target.Url);
|
|
var response = await client.SendAsync(request);
|
|
|
|
// Un 404 ne lève pas : il répond simplement sans Content-Length.
|
|
// Le traiter comme un échec est le seul moyen de ne pas confondre
|
|
// « blob absent » et « blob de 0 octet ».
|
|
if (response.Content.Headers.ContentLength.HasValue)
|
|
result.Record(target.Id, response.Content.Headers.ContentLength.Value);
|
|
else
|
|
result.RecordUnsized(target.Id);
|
|
}
|
|
catch
|
|
{
|
|
result.RecordUnsized(target.Id);
|
|
}
|
|
}));
|
|
}
|
|
|
|
return result;
|
|
}
|
|
}
|
|
}
|