Multilocativité et idempotence

# gateway.env
# Owner pool — runs migrations and privileged maintenance
AIHUMMER_DATABASE_URL=postgres://aihummer:***@localhost:5432/aihummer?sslmode=disable
# Restricted role — activates RLS for normal request traffic
AIHUMMER_DB_APP_URL=postgres://aihummer_app:***@localhost:5432/aihummer?sslmode=disable

side-effect requested
   └─▶ compute resume-stable ledger key
         └─▶ barrier: key already committed?
               ├─ yes ─▶ skip (no double-send)
               └─ no  ─▶ perform effect ─▶ commit key

AiHummer est **multi-tenant**: une passerelle peut desservir plusieurs espaces de travail à partir d'une seule base de données tout en gardant leurs données séparées. Deux mécanismes rendent cela sûr — **Sécurité au niveau des lignes de Postgres (RLS)** pour l'isolation lecture/écriture, et un **couche d'idempotence** afin que les nouvelles tentatives et la récupération de tours ne dupliquent jamais un effet secondaire réel. **Niveau :** L'isolation multitenant au niveau des lignes par la sécurité est limitée par le paiement **Entreprise** niveau — pas partie de la plateforme gratuite/Communauté ; la couche d'iddempotence fait partie du cœur. ## Isolation des locataires avec la sécurité au niveau des lignes L'isolation est appliquée au niveau de la base de données, pas seulement dans le code de l'application. AiHummer exécute des requêtes à travers un **rôle Postgres restreint** (`aihummer_app`) qui a des politiques RLS appliquées, de sorte que la base de données elle-même rejette les lignes qui n'appartiennent pas au locataire actif. RLS est **s'inscrire**. Vous l'activez en donnant à la passerelle une seconde chaîne de connexion pour le rôle restreint : ```ini # gateway.env # Owner pool — runs migrations and privileged maintenance AIHUMMER_DATABASE_URL=postgres://aihummer:***@localhost:5432/aihummer?sslmode=disable # Restricted role — activates RLS for normal request traffic AIHUMMER_DB_APP_URL=postgres://aihummer_app:***@localhost:5432/aihummer?sslmode=disable ``` > [!NOTE] > Pour les installations natives sur l'hôte, l'installateur configure `AIHUMMER_DB_APP_URL` > automatiquement, donc RLS est activé par défaut dans un déploiement standard. Si le > La variable est absente, la passerelle fonctionne uniquement sur le pool propriétaire et le RLS ne l'est pas. > actif. ### Portée par locataire Dans le rôle restreint, chaque requête est limitée à son locataire : la passerelle définit le contexte du locataire actuel sur la connexion afin que les politiques RLS se résolvent par rapport au bon espace de travail. `WHERE tenant_id = …` les filtres ne sont pas faits à la main partout ; la politique les applique de manière centralisée, ce qui signifie qu'un filtre manqué ne peut pas divulguer les lignes d'un autre locataire. ### Système / mode de contournement Certain travail est légitimement inter-locataire — des travailleurs en arrière-plan, des planificateurs et des tâches de maintenance qui fonctionnent sur l'ensemble de l'instance. Ceux-ci s'exécutent dans un **système / mode de contournement** afin qu'ils puissent voir ce dont ils ont besoin. Le contournement est réservé aux travailleurs internes de confiance, pas aux chemins de traitement des demandes. > [!WARNING] > **Les migrations s'exécutent toujours sur le pool propriétaire**, jamais sous le rôle restreint. > La connexion du propriétaire a les privilèges pour modifier le schéma et appliquer le RLS > politiques ; le rôle restreint ne le fait délibérément pas. Gardez les deux connexions > chaînes distinctes et accorder le `aihummer_app` joue seulement ce dont il a besoin. ## Effets secondaires idempotents Un tour peut produire des effets secondaires dans le monde réel : envoyer du courrier, publier un message de retour sur un canal. Si un tour est réessayé — en raison d'une erreur passagère, ou parce que la passerelle a redémarré au milieu du tour et que la récupération le rejoue — ces effets secondaires doivent **pas** se produire deux fois. AiHummer garantit cela avec deux pièces coopérantes. ### Une clé de grand livre stable de CV Chaque effet secondaire est enregistré contre un **clé de grand livre stable de résumé**: une clé qui est dérivée de manière déterministe du tour, donc une répétition du même tour calcule la *même* clé plutôt qu'une nouvelle. Le grand livre se souvient des clés qui ont déjà été utilisées. ### Une barrière aux effets secondaires Avant un effet tel que **courriel** ou **envoyer-canal** est effectué, il passe à travers un **barrière d'effet secondaire** qui vérifie le grand livre. Si cette clé a déjà été activée, la barrière se court-circuite et l'effet est ignoré ; sinon, l'effet s'exécute et la clé est validée. ```text side-effect requested └─▶ compute resume-stable ledger key └─▶ barrier: key already committed? ├─ yes ─▶ skip (no double-send) └─ no ─▶ perform effect ─▶ commit key ``` Le résultat est **comportement externe exactement-une-fois même si la livraison est au moins-une-fois en interne**. Les nouvelles tentatives sont sûres par conception, ce qui permet la récupération des tournants (voir [Livraison et récupération fiables](/fr/v1.0/architecture/delivery-outbox)) rejouer un tour interrompu sans que le client ne reçoive deux fois le même e-mail ou la même réponse. > [!TIP] > C’est pourquoi AiHummer peut offrir une livraison garantie et une récupération automatique des virages > sans le risque habituel de messages en double — l'idempotence est la base > les garanties de livraison sont construites sur. ## Où aller ensuite - Le temps d'exécution qui fait tourner : [Passerelle et moteur de rotation](/fr/v1.0/architecture/gateway-turn-engine). - Comment les réponses sont renvoyées exactement une fois : [Livraison et récupération fiables](/fr/v1.0/architecture/delivery-outbox).