Aller au contenu principal

Updates

Imaginez qu'un opérateur télécharge correctement un update, mais que le nouveau processus échoue au health probe. Installer définitivement ces bytes transformerait un deployment récupérable en downtime.

Les updates AppCore traitent les artefacts applicatifs comme des bytes opaques. Le Runtime valide identité, progression de version, compatibilité, authenticité, checksum, staging, activation, health et rollback. Il n'inspecte pas le code applicatif et n'effectue aucune migration de schéma métier.

Pourquoi un fichier plus récent n'est-il pas automatiquement valide ?​

Une requête d'update contient l'identité de l'application installée, sa version courante et le channel choisi. Le provider peut renvoyer un descriptor candidat. Le coordinator le rejette lorsque :

  • l'application ID diffère ;
  • le channel diffère ;
  • la version candidate n'avance pas la version installée ;
  • l'artefact actif porte un autre application ID ;
  • le build ID candidat réutilise le build ID actif ;
  • la version candidate n'avance pas la version active ;
  • le runtime requirement ou la protocol version est incompatible.

Qu'est-ce qui prouve qu'un artefact est autorisé ?​

Les coordinators de production exigent un verifier explicite d'authenticité. La vérification Ed25519 emploie les trust roots appartenant au deployment. Elles peuvent être active, deprecated ou revoked. Une clé revoked rejette tout artefact.

La policy peut aussi autoriser des channels et origins exacts avant la vérification de signature. Les artefacts locaux unsigned de développement exigent une feature de compilation et des contrôles stricts du file root ; ce n'est jamais un fallback automatique.

Le payload signé couvre les champs stables du descriptor : application ID, application version, build ID, channel, runtime requirement, protocol version, artifact reference, SHA-256 et taille.

Que se passe-t-il entre le download et le commit ?​

Le chemin two-phase existe pour vérifier la health au niveau du processus. Un parent peut préparer et activer un candidat, redémarrer/tester le child, puis commit ou rollback selon la health observée.

Quand le rollback intervient-il ?​

Si l'activation échoue après l'existence d'un artefact précédent, le coordinator restaure ce dernier et rapporte le descriptor tenté et la raison. Des points de fault injection existent après selection, verification, staging, activation, health verification et avant commit afin que les tests prouvent le rollback.

Pourquoi le code d'update tient-il compte du filesystem ?​

Les lectures rejettent les symlinks, fichiers non réguliers et fichiers au-delà de la limite configurée. L'activation revérifie taille et SHA-256 avant d'installer des artefacts de build immuables. Les paths existants ne sont pas écrasés, sauf réutilisation idempotente avec des bytes exactement identiques.

Limites​

  • Les updates n'effectuent pas automatiquement les migrations de schéma métier.
  • Ils ne prouvent pas la correction sémantique de la nouvelle version ; les health checks ne testent que le probe configuré.
  • Ils ne gèrent pas les credentials externes du deployment.
  • La production exige un verifier d'authenticité. Les artefacts locaux unsigned sont réservés au développement et aux tests.
  • Le rollback couvre l'artifact store et l'activation state ; il n'annule pas les effets externes créés par la nouvelle version applicative.

Continuez avec le modèle de sécurité.

Composition explicite du cycle de vie du host​

HostUpdateFlow compose ActivationAdapter, UpdateRecoveryGate et le journal V2 existant. Deployment possède un lock externe unique, staging authentifié, deadlines de drain, snapshots liés à l’installation, démarrage/arrêt et readiness réelle. Prepare persiste l’intention avant callbacks ; activate répète drain/snapshot/préparation idempotents et scelle les écritures avant le host. Les callbacks respectent les limites d’exécution du deployment. Les receipts pending survivent aux interruptions. Un receipt prepared après activate interrompu ne prouve pas l’absence d’activation : inspectez le host par recover ou exigez une revue manuelle. Échec de santé enregistre le rollback requis. Commit du host précède committed ; commit ambigu ne termine jamais. Rollback exige une identité réelle revérifiée avant RecordRolledBack. Conservez artefacts/données précédents jusqu’à santé et fin récupérable. Les replays terminaux valident les digests. La version avance avec build distinct, plateforme/target et hash ; des builds de même version ne sont pas des upgrades automatiques. Aucune dépendance Tauri, container ou gestionnaire de processus.