---
# L'ORDRE DE CE FICHIER EST L'ORDRE D'EXECUTION, ET C'EST LUI QUI COMPTE (2026-09-14).
#
# Ansible declenche les handlers dans l'ordre ou ils sont DEFINIS ICI — jamais dans
# l'ordre ou les taches les ont notifies. Le redemarrage est donc ecrit EN PREMIER, et
# ce n'est pas une preference de style.
#
# CE QUE L'ORDRE INVERSE COUTAIT. Sur un premier deploiement, `main.cf` passe
# `inet_protocols` de `all` a `ipv4` (notifie un REDEMARRAGE) et les cartes LDAP changent
# aussi (notifient un RECHARGEMENT). Les deux sont en file. Le rechargement partait
# d'abord, sur un maitre qui portait encore l'ancienne valeur :
#
#   warning: to change inet_protocols, stop and start Postfix
#   fatal: :::submission: Address family for hostname not supported
#
# Postfix tombe en `failed` APRES avoir accepte une configuration valide — `postfix check`
# ne dit rien, parce que la configuration EST valide ; c'est la TRANSITION qui ne l'est
# pas. Le role documentait deja le piege depuis le 2026-08-30 et notifiait correctement ;
# seul l'ordre des handlers le rendait inoperant.
#
# Redemarrer d'abord rend le rechargement qui suit inoffensif : il s'applique a un maitre
# deja reparti, donc deja aligne.
- name: Redémarrer postfix
  ansible.builtin.systemd:
    name: "{{ serveur_postfix_service }}"
    state: restarted
  when: not ansible_check_mode

# Le rechargement reste le geste ORDINAIRE — cartes, alias, tables LDAP : tout ce qui ne
# vit pas dans le processus maitre. Ce qui y vit — protocoles, adresses, ports — exige un
# redemarrage, et c'est la meme frontiere que pour nginx et son `listen`.
- name: Recharger postfix
  ansible.builtin.systemd:
    name: "{{ serveur_postfix_service }}"
    state: reloaded
  when: not ansible_check_mode