Le Docker Build de arcodange/kadans (main 46677aec) a rougi deux fois sur l'envoi d'une grosse couche au registre de Gitea (run 9220 et son rejeu). Le journal de Gitea (pi2, docker logs gitea), à la minute près :
18:31:35 PUT /v2/arcodange/kadans/blobs/uploads/…380b34bc… → 201 Created in 19796.7ms
18:32:15 PutBlobsUpload() [E] Package registry API internal error: 500 offset mismatch between file and model
18:32:18 PutBlobsUpload() [E] Package registry API internal error: 500 unexpected EOF
18:32:18 PUT /v2/arcodange/kadans/blobs/uploads/mlwuoyura… → 500 Internal Server Error in 64465.5ms
L'envoi qui échoue est coupé (unexpected EOF) au bout de 64,5 s ; les réessais sur la même session d'envoi échouent ensuite en offset mismatch.
La couche précédente est passée en 19,8 s.
Le stockage de Gitea est sain : 218 Gio libres sur /mnt/arcodange de pi2, 56 Gio sur la carte SD.
La cause
gitea.arcodange.lab passe par Traefik (IngressRoute kube-system/gitea → Service gitea-external, ExternalName 192.168.1.202:3000). Traefik v3.6.2 tourne sansrespondingTimeouts : le défaut de la v3 s'applique, readTimeout à 60 s sur chaque point d'entrée. Tout corps de requête lu en plus de 60 s est coupé.
La limite existait déjà ; ce qui a changé ce jour-là, c'est la vitesse : pi2 (disque USB 2) portait des reconstructions Longhorn (charge 21 sur 15 min, retombée à 6 vers 19 h 30), et Gitea écrit ses couches sur ce même disque.
Ce qu'on peut faire (à arbitrer, rien n'est appliqué)
Allonger le délai de lecture du point d'entrée websecure (par exemple 600 s) via la HelmChartConfig de Traefik de k3s : --entryPoints.websecure.transport.respondingTimeouts.readTimeout=600s. Cela vaut pour TOUT ce qui passe par websecure, pas seulement la forge.
Ou un point d'entrée dédié à la forge, avec son propre délai.
Ou ne rien changer, et rejouer au calme — ce qui a été fait le 26/09 (rejeu du run 9220 une fois pi2 retombé).
Rapporté par la session df1357ca (kadans).
## Constat (2026-09-26)
Le Docker Build de `arcodange/kadans` (main 46677aec) a rougi **deux fois** sur l'envoi d'une grosse couche au registre de Gitea (run 9220 et son rejeu). Le journal de Gitea (pi2, `docker logs gitea`), à la minute près :
```
18:31:35 PUT /v2/arcodange/kadans/blobs/uploads/…380b34bc… → 201 Created in 19796.7ms
18:32:15 PutBlobsUpload() [E] Package registry API internal error: 500 offset mismatch between file and model
18:32:18 PutBlobsUpload() [E] Package registry API internal error: 500 unexpected EOF
18:32:18 PUT /v2/arcodange/kadans/blobs/uploads/mlwuoyura… → 500 Internal Server Error in 64465.5ms
```
- L'envoi qui échoue est **coupé** (`unexpected EOF`) au bout de **64,5 s** ; les réessais sur la même session d'envoi échouent ensuite en `offset mismatch`.
- La couche précédente est passée en 19,8 s.
- **Le stockage de Gitea est sain** : 218 Gio libres sur `/mnt/arcodange` de pi2, 56 Gio sur la carte SD.
## La cause
`gitea.arcodange.lab` passe par Traefik (`IngressRoute kube-system/gitea` → `Service gitea-external`, ExternalName 192.168.1.202:3000). Traefik **v3.6.2** tourne **sans** `respondingTimeouts` : le défaut de la v3 s'applique, **`readTimeout` à 60 s** sur chaque point d'entrée. Tout corps de requête lu en plus de 60 s est coupé.
La limite existait déjà ; ce qui a changé ce jour-là, c'est la **vitesse** : pi2 (disque USB 2) portait des reconstructions Longhorn (charge 21 sur 15 min, retombée à 6 vers 19 h 30), et Gitea écrit ses couches sur ce même disque.
## Ce qu'on peut faire (à arbitrer, rien n'est appliqué)
1. **Allonger le délai de lecture du point d'entrée `websecure`** (par exemple 600 s) via la `HelmChartConfig` de Traefik de k3s : `--entryPoints.websecure.transport.respondingTimeouts.readTimeout=600s`. Cela vaut pour TOUT ce qui passe par `websecure`, pas seulement la forge.
2. Ou un point d'entrée dédié à la forge, avec son propre délai.
3. Ou ne rien changer, et rejouer au calme — ce qui a été fait le 26/09 (rejeu du run 9220 une fois pi2 retombé).
Rapporté par la session df1357ca (kadans).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Constat (2026-09-26)
Le Docker Build de
arcodange/kadans(main 46677aec) a rougi deux fois sur l'envoi d'une grosse couche au registre de Gitea (run 9220 et son rejeu). Le journal de Gitea (pi2,docker logs gitea), à la minute près :unexpected EOF) au bout de 64,5 s ; les réessais sur la même session d'envoi échouent ensuite enoffset mismatch./mnt/arcodangede pi2, 56 Gio sur la carte SD.La cause
gitea.arcodange.labpasse par Traefik (IngressRoute kube-system/gitea→Service gitea-external, ExternalName 192.168.1.202:3000). Traefik v3.6.2 tourne sansrespondingTimeouts: le défaut de la v3 s'applique,readTimeoutà 60 s sur chaque point d'entrée. Tout corps de requête lu en plus de 60 s est coupé.La limite existait déjà ; ce qui a changé ce jour-là, c'est la vitesse : pi2 (disque USB 2) portait des reconstructions Longhorn (charge 21 sur 15 min, retombée à 6 vers 19 h 30), et Gitea écrit ses couches sur ce même disque.
Ce qu'on peut faire (à arbitrer, rien n'est appliqué)
websecure(par exemple 600 s) via laHelmChartConfigde Traefik de k3s :--entryPoints.websecure.transport.respondingTimeouts.readTimeout=600s. Cela vaut pour TOUT ce qui passe parwebsecure, pas seulement la forge.Rapporté par la session df1357ca (kadans).