[shikanime]

Quoi

Nouvelle section « Archivage d'un projet » dans Administration > Projets : ordre des opérations (verrouillage, nettoyage des ressources externes, archivage), comportement en cas d'échec (statut échoué, erreur 422, suppression rejouable), conflit de modification (409), et déverrouillage par un administrateur.

Pourquoi

La console a fiabilisé la suppression concurrente des projets (verrouillage du projet pendant la suppression externe, rejet de l'archivage d'un snapshot obsolète, nettoyage externe piloté avant l'archivage). Le comportement observable par les utilisateurs et administrateurs méritait d'être documenté.

Références

• cloud-pi-native/console@90499a69 fix(server-nestjs): fiabiliser la suppression concurrente et le statut archive
• cloud-pi-native/console@544543e7 fix(server-nestjs): verrouiller le projet pendant la suppression externe
• cloud-pi-native/console@b740e364 fix(server-nestjs): rejeter l'archivage d'un snapshot obsolete
• cloud-pi-native/console@5ac6595b fix(server-nestjs): comparer l'archivage au snapshot pose du verrou
• cloud-pi-native/console@9c9e8d32 fix(project): piloter la suppression externe avant d'archiver la ligne

[StephaneTrebel]

L’ordre verrouillage → nettoyage externe → archivage, les statuts et les erreurs 422/409 correspondent au code Console actuel, mais l’idempotence de tous les nettoyages est affirmée à tort : le cas contraire reste documenté dans Console #2785 et présent dans le chemin project.delete, comme détaillé inline. Les liens locaux, la structure Markdown et Test app build sont valides ; aucune suite applicative locale n’a été exécutée pour ce diff documentaire. Le suivi #119 couvre également la clarification suppression/archivage et la demande répétée sur un projet déjà archivé ; cette MR en couvre une partie, sans solder son ledger.

[StephaneTrebel]

🟠 important (documentation): Ne pas garantir l’idempotence de tous les nettoyages

Le verrouillage permet de relancer la demande, mais ne rend pas automatiquement idempotente chaque suppression dans les services externes. La nouvelle justification est trop forte :

+- Si le nettoyage échoue sur un service, le projet passe au statut « échoué » et l'API renvoie une erreur 422. Les nettoyages étant idempotents, la suppression peut être rejouée telle quelle.

À la référence Console 17e109e2, le chemin project.delete → SonarqubeService.handleDelete → deleteProjectGroup appelle encore client.deleteProject sans tolérance du 404 ; le client HTTP propage toute réponse >= 400. Si deux nettoyages ont listé le même projet SonarQube, celui qui le supprime en second peut donc encore échouer parce qu’il est déjà absent. Ce comportement est précisément suivi dans Console #2785, toujours ouverte, y compris pour le site d’appel project.delete.

Sources : suppression de groupe projet SonarQube, client de suppression et propagation des erreurs HTTP.

Conserver l’explication du statut et de la possibilité de reprise, mais retirer la garantie générale : préciser qu’une partie des ressources peut déjà avoir été supprimée et qu’il faut examiner/corriger l’erreur du service en échec avant de relancer, sans promettre qu’un rejeu identique suffira. Le correctif backend reste hors périmètre de cette MR documentaire.