admin_ekaii/ekaii-mirror

Fork 0

Têtes de joueurs absentes sur Discord (webhook EkaiiMirrorVelocity) — Crafatar HS, changer de fournisseur d'avatar #1

New issue

Closed

opened 2026-08-31 10:41:10 +00:00 by wait4mi · 2 comments

wait4mi commented

2026-08-31 10:41:10 +00:00

Symptôme

Depuis quelques jours, les messages postés sur le Discord Ekaii par le pont MC (join/leave, chat, morts, advancements) n'affichent plus la tête du joueur : à la place, une image placeholder de base (cassée). Avant, la tête correspondait au skin du joueur.

Cause (diagnostic du 2026-08-31)

Le pont Discord, c'est EkaiiMirrorVelocity (module velocity-plugin), pas DiscordSRV (il n'y a plus de jar DiscordSRV sur minis — juste un dossier config orphelin dans creaclone/plugins/).

L'URL de l'avatar est codée en dur dans velocity-plugin/src/main/java/fr/ekaii/mirror/velocity/DiscordPublisher.java :

private static String crafatar(UUID uuid) {
    return "https://crafatar.com/avatars/" + uuid + "?overlay&size=64";
}

utilisée par publishChat (avatar_url du webhook), publishDeath, publishAdvancement et buildPresenceEmbed (author.icon_url).

Crafatar est en panne (côté Crafatar ↔ Mojang, rien à voir avec notre infra) — testé avec les UUID réels de 6 joueurs Ekaii (usercache Survie) :

Test	Résultat
`https://crafatar.com/avatars/<uuid>?overlay&size=64`	200 mais header `x-storage-type: user error` ou `server error` selon les appels, et la même image pour les 6 joueurs (md5 identique = fallback Crafatar)
idem avec `&default=404`	307 → `404` : Crafatar avoue qu'il n'a pas le skin
`https://sessionserver.mojang.com/session/minecraft/profile/<uuid>`	200 pour les 6 → les comptes sont bien résolus par Mojang

Comme c'est Discord qui va chercher l'image chez Crafatar (le proxy ne fait que passer l'URL), le réseau de minis n'est pas en cause. Rien dans les logs mc-velocity (le plugin ne loggue pas les échecs webhook), config sans option d'avatar, online-mode = true sur le proxy → aucun changement côté Ekaii ; c'est le fournisseur externe qui a lâché.

Fournisseurs alternatifs testés (mêmes 6 UUID, image distincte pour chaque joueur = vrai skin)

Service	URL (UUID avec tirets accepté)
mc-heads.net	`https://mc-heads.net/avatar/<uuid>/64`
crafthead.net	`https://crafthead.net/helm/<uuid>/64`
minotar.net	`https://minotar.net/helm/<uuid>/64.png`
cravatar.eu	`https://cravatar.eu/helmavatar/<uuid>/64.png`

Fix proposé

Remplacer Crafatar par un autre fournisseur (proposition : mc-heads.net, stable, /avatar inclut déjà le calque casque), et rendre l'URL configurable pour ne pas devoir rebuilder la prochaine fois qu'un service tombe.

-    private static String crafatar(UUID uuid) {
-        return "https://crafatar.com/avatars/" + uuid + "?overlay&size=64";
-    }
+    private static String avatar(UUID uuid) {
+        return avatarTemplate.replace("{uuid}", uuid.toString());
+    }

avec dans velocity-plugin/src/main/resources/config.yml :

discord:
  enabled: true
  webhook-url: "..."
  # Modèle d'URL d'avatar. Placeholders : {uuid}
  # Crafatar est HS depuis fin août 2026 (fallback pour tout le monde).
  avatar-url: "https://mc-heads.net/avatar/{uuid}/64"

(valeur par défaut dans le code = mc-heads si la clé est absente, pour rester compatible avec la config actuelle en prod).

Variante minimale si on ne veut pas toucher à la config : juste remplacer la string, une ligne.

Déploiement

Ce repo : patch + bump 1.4.1 → 1.4.2, commit, tag v1.4.2 → la CI (.forgejo/workflows/build.yml) construit et publie la release avec EkaiiMirrorVelocity-1.4.2.jar.
exo/ekaii-mc-stack → plugins/manifest.yml (section velocity) : jar / tag / artifact → 1.4.2, commit avec Reason: + Broadcast: → sync GitOps → restart de Velocity (~35 s, chat inter-serveurs et TAB coupés pendant ce temps). À faire à une heure creuse.
Vérification : un join/leave doit afficher la tête. Note : Discord met en cache les images proxifiées, les messages déjà postés garderont leur placeholder ; seuls les nouveaux seront corrects.

Rollback : remettre 1.4.1 dans le manifest.

Statut

Feu vert d'exo sur le principe + choix du fournisseur (mc-heads proposé)
Patch + tag v1.4.2
Bump manifest ekaii-mc-stack
Validation en prod (tête visible sur un join)

## Symptôme Depuis quelques jours, les messages postés sur le Discord Ekaii par le pont MC (join/leave, chat, morts, advancements) n'affichent plus la tête du joueur : à la place, une image placeholder de base (cassée). Avant, la tête correspondait au skin du joueur. ## Cause (diagnostic du 2026-08-31) Le pont Discord, c'est **EkaiiMirrorVelocity** (module `velocity-plugin`), pas DiscordSRV (il n'y a plus de jar DiscordSRV sur minis — juste un dossier config orphelin dans `creaclone/plugins/`). L'URL de l'avatar est codée en dur dans `velocity-plugin/src/main/java/fr/ekaii/mirror/velocity/DiscordPublisher.java` : ```java private static String crafatar(UUID uuid) { return "https://crafatar.com/avatars/" + uuid + "?overlay&size=64"; } ``` utilisée par `publishChat` (`avatar_url` du webhook), `publishDeath`, `publishAdvancement` et `buildPresenceEmbed` (`author.icon_url`). **Crafatar est en panne** (côté Crafatar ↔ Mojang, rien à voir avec notre infra) — testé avec les UUID réels de 6 joueurs Ekaii (usercache Survie) : | Test | Résultat | |---|---| | `https://crafatar.com/avatars/<uuid>?overlay&size=64` | 200 mais header `x-storage-type: user error` ou `server error` selon les appels, et **la même image pour les 6 joueurs** (md5 identique = fallback Crafatar) | | idem avec `&default=404` | 307 → `404` : Crafatar avoue qu'il n'a pas le skin | | `https://sessionserver.mojang.com/session/minecraft/profile/<uuid>` | 200 pour les 6 → les comptes sont bien résolus par Mojang | Comme c'est **Discord** qui va chercher l'image chez Crafatar (le proxy ne fait que passer l'URL), le réseau de minis n'est pas en cause. Rien dans les logs `mc-velocity` (le plugin ne loggue pas les échecs webhook), config sans option d'avatar, `online-mode = true` sur le proxy → aucun changement côté Ekaii ; c'est le fournisseur externe qui a lâché. ## Fournisseurs alternatifs testés (mêmes 6 UUID, image distincte pour chaque joueur = vrai skin) | Service | URL (UUID avec tirets accepté) | |---|---| | mc-heads.net | `https://mc-heads.net/avatar/<uuid>/64` | | crafthead.net | `https://crafthead.net/helm/<uuid>/64` | | minotar.net | `https://minotar.net/helm/<uuid>/64.png` | | cravatar.eu | `https://cravatar.eu/helmavatar/<uuid>/64.png` | ## Fix proposé Remplacer Crafatar par un autre fournisseur (proposition : **mc-heads.net**, stable, `/avatar` inclut déjà le calque casque), et rendre l'URL configurable pour ne pas devoir rebuilder la prochaine fois qu'un service tombe. ```diff - private static String crafatar(UUID uuid) { - return "https://crafatar.com/avatars/" + uuid + "?overlay&size=64"; - } + private static String avatar(UUID uuid) { + return avatarTemplate.replace("{uuid}", uuid.toString()); + } ``` avec dans `velocity-plugin/src/main/resources/config.yml` : ```yaml discord: enabled: true webhook-url: "..." # Modèle d'URL d'avatar. Placeholders : {uuid} # Crafatar est HS depuis fin août 2026 (fallback pour tout le monde). avatar-url: "https://mc-heads.net/avatar/{uuid}/64" ``` (valeur par défaut dans le code = mc-heads si la clé est absente, pour rester compatible avec la config actuelle en prod). Variante minimale si on ne veut pas toucher à la config : juste remplacer la string, une ligne. ## Déploiement 1. Ce repo : patch + bump `1.4.1 → 1.4.2`, commit, **tag `v1.4.2`** → la CI (`.forgejo/workflows/build.yml`) construit et publie la release avec `EkaiiMirrorVelocity-1.4.2.jar`. 2. `exo/ekaii-mc-stack` → `plugins/manifest.yml` (section `velocity`) : `jar` / `tag` / `artifact` → `1.4.2`, commit avec `Reason:` + `Broadcast:` → sync GitOps → **restart de Velocity (~35 s, chat inter-serveurs et TAB coupés pendant ce temps)**. À faire à une heure creuse. 3. Vérification : un join/leave doit afficher la tête. Note : Discord met en cache les images proxifiées, les messages déjà postés garderont leur placeholder ; seuls les nouveaux seront corrects. Rollback : remettre `1.4.1` dans le manifest. ## Statut - [ ] Feu vert d'exo sur le principe + choix du fournisseur (mc-heads proposé) - [ ] Patch + tag `v1.4.2` - [ ] Bump manifest `ekaii-mc-stack` - [ ] Validation en prod (tête visible sur un join)

wait4mi commented

2026-08-31 10:47:14 +00:00

Author

Vérification « c'est bien ce plugin qui poste sur Discord ? » (2026-08-31)

Le webhook configuré dans velocity/plugins/ekaii-mirror-velocity/config.yml (discord.webhook-url) s'appelle EkaiiSRV côté Discord et vise le salon 1186576981156954122 (guild 1185979056626356265).
L'ancienne config DiscordSRV (creaclone/plugins/DiscordSRV/config.yml, dernier jar vu 2026-05-22, plus aucun jar chargé depuis) visait exactement le même salon pour global/status/awards/deaths/join/leave.
La section discord: du plugin Velocity est datée « Added by deploy 2026-05-22 » : DiscordSRV a été remplacé ce jour-là par EkaiiMirrorVelocity, en réutilisant le webhook existant — d'où le nom EkaiiSRV qui laisse croire que DiscordSRV tourne encore.
Wiring dans le code : ChatBridge.java:45 → publishChat, HookEventBridge.java:66-68 → publishDeath/publishAdvancement, PresenceManager → embed join/leave. exo/ekaii-bot (NAS) ne poste aucun avatar de joueur (galerie + whitelist uniquement) ; aucun autre repo Forgejo ne fait de pont chat MC ↔ Discord.

**Vérification « c'est bien ce plugin qui poste sur Discord ? »** (2026-08-31) - Le webhook configuré dans `velocity/plugins/ekaii-mirror-velocity/config.yml` (`discord.webhook-url`) s'appelle **`EkaiiSRV`** côté Discord et vise le salon `1186576981156954122` (guild `1185979056626356265`). - L'ancienne config DiscordSRV (`creaclone/plugins/DiscordSRV/config.yml`, dernier jar vu 2026-05-22, plus aucun jar chargé depuis) visait **exactement le même salon** pour global/status/awards/deaths/join/leave. - La section `discord:` du plugin Velocity est datée « Added by deploy 2026-05-22 » : DiscordSRV a été remplacé ce jour-là par EkaiiMirrorVelocity, en réutilisant le webhook existant — d'où le nom `EkaiiSRV` qui laisse croire que DiscordSRV tourne encore. - Wiring dans le code : `ChatBridge.java:45` → `publishChat`, `HookEventBridge.java:66-68` → `publishDeath`/`publishAdvancement`, `PresenceManager` → embed join/leave. `exo/ekaii-bot` (NAS) ne poste aucun avatar de joueur (galerie + whitelist uniquement) ; aucun autre repo Forgejo ne fait de pont chat MC ↔ Discord.

admin_ekaii referenced this issue from a commit

2026-08-31 11:18:15 +00:00

v1.4.2: Discord avatars — Crafatar is down, switch to mc-heads.net + configurable avatar-url template

admin_ekaii closed this issue

2026-08-31 11:18:15 +00:00

admin_ekaii referenced this issue from a commit

2026-08-31 11:18:22 +00:00

v1.4.2: Discord avatars — Crafatar is down, switch to mc-heads.net + configurable avatar-url template

wait4mi referenced this issue

2026-08-31 11:19:46 +00:00

Chat Discord → Minecraft absent : rien ne remplace DiscordSRV, implémenter l'inbound dans EkaiiMirrorVelocity #2

admin_ekaii referenced this issue from a commit

2026-08-31 11:21:48 +00:00

velocity: EkaiiMirrorVelocity 1.4.1 -> 1.4.2 (Discord player heads via mc-heads.net)

admin_ekaii commented

2026-08-31 11:27:41 +00:00

Owner

Contre-vérification indépendante (2026-08-31) — diagnostic CONFIRMÉ, fix déployé

Diagnostic re-testé depuis zéro (autre session, autres requêtes) :

6 UUID réels du usercache Survie → Crafatar renvoie la même image pour les 6 (md5 identique 2024af6a…, y compris pour un UUID inventé) avec x-storage-type: server error. Panne confirmée côté Crafatar.
Nuance vs le diagnostic initial : &default=404 renvoie maintenant 200 (plus de 307), et les comptes anciens très cachés (Notch, jeb_) servent encore leur vrai skin — la panne touche la résolution Mojang, pas le cache historique. Ça ne change rien à la conclusion.
mc-heads.net → 6 images distinctes (vrais skins) pour les mêmes UUID. Choix validé.
Le patch proposé était incomplet : 5e occurrence de l'URL Crafatar dans SecurityAuditor.java (embeds d'audit), corrigée aussi.

Livré :

v1.4.2 (main, commit 89a20c1) : discord.avatar-url configurable (placeholder {uuid}), défaut mc-heads en code (compatible config existante), utilisé par chat/mort/advancement/présence et les embeds d'audit. Release CI publiée avec EkaiiMirrorVelocity-1.4.2.jar.
Cherry-pick sur mc-26.2 (le module velocity y était identique, il aurait régressé).
Bonus : la ligne de log de démarrage disait v1.4.1 en dur → lit maintenant la version de l'annotation @Plugin (bdcd3e2, partira avec la prochaine release).
ekaii-mc-stack d2d2750 : manifest 1.4.1→1.4.2 + avatar-url explicite dans la config gitops. Sync 11:21:49Z, restart graceful de Velocity (broadcast 30 s, 2 joueurs en ligne), up en ~35 s.

Vérification prod :

Loaded plugin ekaii-mirror-velocity 1.4.2, discord=ON, aucun warn [Discord].
TyRex1110 et Shurnwilrra se sont reconnectés à 11:22:30/36 → embeds join postés sans erreur.
Test webhook ?wait=true avec l'icône mc-heads de TyRex1110 : Discord a généré le proxy_icon_url (son media-proxy a bien récupéré l'image) — message de test auto-supprimé.

Les anciens messages gardent leur placeholder (cache Discord), seuls les nouveaux ont la tête — attendu.

Rollback si besoin : manifest → 1.4.1.

🤖 Vérifié et déployé par Claude (session autonome, à la demande de Paul).

## Contre-vérification indépendante (2026-08-31) — diagnostic CONFIRMÉ, fix déployé **Diagnostic re-testé depuis zéro** (autre session, autres requêtes) : - 6 UUID réels du usercache Survie → Crafatar renvoie **la même image pour les 6** (md5 identique `2024af6a…`, y compris pour un UUID inventé) avec `x-storage-type: server error`. Panne confirmée côté Crafatar. - Nuance vs le diagnostic initial : `&default=404` renvoie maintenant 200 (plus de 307), et les comptes anciens très cachés (Notch, jeb_) servent encore leur vrai skin — la panne touche la résolution Mojang, pas le cache historique. Ça ne change rien à la conclusion. - mc-heads.net → 6 images distinctes (vrais skins) pour les mêmes UUID. Choix validé. - Le patch proposé était incomplet : **5e occurrence** de l'URL Crafatar dans `SecurityAuditor.java` (embeds d'audit), corrigée aussi. **Livré :** - `v1.4.2` (main, commit 89a20c1) : `discord.avatar-url` configurable (placeholder `{uuid}`), défaut mc-heads en code (compatible config existante), utilisé par chat/mort/advancement/présence **et** les embeds d'audit. Release CI publiée avec `EkaiiMirrorVelocity-1.4.2.jar`. - Cherry-pick sur `mc-26.2` (le module velocity y était identique, il aurait régressé). - Bonus : la ligne de log de démarrage disait `v1.4.1` en dur → lit maintenant la version de l'annotation `@Plugin` (bdcd3e2, partira avec la prochaine release). - `ekaii-mc-stack` d2d2750 : manifest 1.4.1→1.4.2 + `avatar-url` explicite dans la config gitops. Sync 11:21:49Z, restart graceful de Velocity (broadcast 30 s, 2 joueurs en ligne), up en ~35 s. **Vérification prod :** - `Loaded plugin ekaii-mirror-velocity 1.4.2`, `discord=ON`, aucun warn `[Discord]`. - TyRex1110 et Shurnwilrra se sont reconnectés à 11:22:30/36 → embeds join postés sans erreur. - Test webhook `?wait=true` avec l'icône mc-heads de TyRex1110 : Discord a généré le `proxy_icon_url` (son media-proxy a bien récupéré l'image) — message de test auto-supprimé. Les anciens messages gardent leur placeholder (cache Discord), seuls les nouveaux ont la tête — attendu. Rollback si besoin : manifest → 1.4.1. 🤖 Vérifié et déployé par Claude (session autonome, à la demande de Paul).

admin_ekaii referenced this issue

2026-08-31 11:29:31 +00:00

Chat Discord → Minecraft absent : rien ne remplace DiscordSRV, implémenter l'inbound dans EkaiiMirrorVelocity #2

wait4mi referenced this issue

2026-09-01 11:04:09 +00:00

Icône Ekaii sur les messages hors chat du webhook EkaiiSRV (join / leave / mort / advancement) — le webhook n'a pas d'avatar #3