Admission, résultats incertains et preuves sur la cible
Lorsqu’un prédicat sélectif est exigé, les filtres UPDATE/DELETE prouvés toujours vrais, comme WHERE 1=1, sont refusés. L’approbation humaine reste liée au plan exact et aux preuves de l’ensemble de lignes.
Les magasins de challenges personnalisés doivent implémenter TryPromoteAsync de manière atomique, pour une instruction comme pour un lot. Redis et la reprise persistante utilisent des enveloppes versionnées. Un challenge incompatible exige un nouvel aperçu et un nouveau consentement. Voir le guide de mise à niveau.
dml.commit_outcome_unknown et dml.rollback_outcome_unknown sont deux résultats distincts, non réessayables. Conservez les preuves d’approbation et de cible pour une vérification indépendante. L’absence de témoin ou de clé Redis ne prouve pas une annulation ; ne rejouez jamais automatiquement une mutation incertaine. Une erreur de persistance d’audit après un commit confirmé ne doit pas être présentée comme un échec de mutation.
AddHsSqlAgentTargetExecutionFence() est facultatif et nécessite de préparer la cible puis de prouver séparément le retrait des droits DML des anciens workers. Chaque commit inscrit effectue deux transactions de vérification supplémentaires, toujours annulées, sur la connexion réelle, puis deux lectures indépendantes après commit pour Admission et Witness. Oracle utilise READ COMMITTED uniquement pour le diagnostic de conflit d’unicité du témoin ; les autres phases utilisent SERIALIZABLE. Des preuves contradictoires donnent un résultat incertain. Cela ne certifie ni l’inscription de toute la flotte ni la réconciliation automatique d’un worker actif.
Le DML suit une voie plus stricte que les Query, car au moment du commit l’approbation doit toujours décrire les mêmes Mutation Evidence.
Un seul Tool pour un ou plusieurs Statements
execute_dml_sql accepte une ou plusieurs instructions UPDATE, DELETE ou INSERT ... VALUES prises en charge. Plusieurs Statements sont séparés par des points-virgules.
Il n’existe pas de Tool batch DML séparé. Une entrée multi-statement devient un Batch, reçoit une seule approbation, s’exécute dans l’ordre d’origine puis est commit de manière atomique dans une Transaction contrôlée par le serveur.
Le Client ne peut pas fournir BEGIN, COMMIT, ROLLBACK ou un autre Transaction-control SQL. Le serveur possède les frontières de Transaction.
Ce que l’approbation lie
Pour UPDATE et DELETE, l’approbation est liée au Primary Key Row Set exact observé pendant le Preview. Chaque Statement est revalidé immédiatement avant sa mutation dans la Commit Transaction.
Pour INSERT ... VALUES, l’approbation lie le Literal Payload immuable et la Command compilée exacte. INSERT ... SELECT reste indisponible tant que la sémantique d’approbation du source Row Set n’est pas définie.
Si un Statement précédent modifie le Row Set approuvé d’un Statement suivant, tout le Batch échoue en mode fail closed et rollback.
Provider d’approbation
MCP Elicitation reste le Provider officiel par défaut. Un Host peut aussi utiliser l’adapter officiel HsSqlAgent.Approvals.Webhook ou implémenter IDmlApprovalProvider avec HsSqlAgent.Server.
Le Provider reçoit des Evidence indépendantes du transport, pas des primitives d’exécution SQL. Il ne reçoit ni Database Connection, ni Transaction, ni Plan validé, ni autorité de commit.
Approbations Pending durables
Un Provider peut retourner Pending pour un Workflow asynchrone. Avec l’Admin Store, hs-sql-agent conserve le Resume Intent protégé et les Approval Fingerprints.
Lorsqu’une décision finale arrive, le serveur recharge l’autorisation et la configuration DB courantes, Parse et Preview à nouveau le DML, compare les Evidence approuvées et crée un nouveau Challenge de courte durée. Une modification de l’autorisation, de la configuration DB, de la Policy, du Plan, du Row Set ou des affected-row Evidence rend la demande stale au lieu de la commit.
La reprise concernel’Intent d’exécution, pas une ancienne Database Session.
Règles fail closed
Une mutation n’est pas commit si l’approbation est refusée, expirée, stale, si le Fingerprint ne correspond plus, si l’autorisation est retirée, si la Policy courante la refuse ou si le Row Set approuvé ne peut pas être reproduit.
Voir Référence des outils MCP, Configuration et Intégration ASP.NET Core.