Skip to content

Ne perd plus une image publiée, ni la dernière version connue - #33

Open
flocom wants to merge 1 commit into
mainfrom
claude/remove-apel-sensitive-data-73l5iu
Open

Ne perd plus une image publiée, ni la dernière version connue#33
flocom wants to merge 1 commit into
mainfrom
claude/remove-apel-sensitive-data-73l5iu

Conversation

@flocom

@flocom flocom commented Aug 2, 2026

Copy link
Copy Markdown
Owner

Deux défauts distincts derrière le même écran « Version et mises à jour ».

1. Des images n'étaient jamais publiées

Le workflow de publication annulait la construction en cours à chaque nouvelle fusion (cancel-in-progress: true), réglage correct pour la vérification des PR mais destructeur pour une publication. Deux fusions séparées de moins que la durée d'une construction (~10 min) suffisaient à tuer la précédente avant qu'elle n'ait poussé son image.

Constaté sur main ce matin : le build de #31 a été annulé par l'arrivée de #32, et latest est resté sur #30 pendant que main était deux commits plus loin. L'updater, qui ne suit que latest, hérite du même retard.

Les publications attendent désormais leur tour. Un commit intermédiaire peut être sauté — GitHub ne garde qu'une exécution en attente par groupe — mais il est de toute façon un ancêtre de celui qui sera publié, donc rien n'est perdu.

2. Un échec de vérification effaçait ce que l'application savait déjà

fetchLatestCommit écrasait le cache par son résultat, y compris en erreur : un seul 403 remplaçait la dernière réponse connue par null et l'écran retombait sur État inconnu, alors qu'il savait encore quelle version était publiée.

La réponse connue est conservée, l'erreur s'affiche à côté et non à la place, et la date affichée est celle de la dernière vérification réellement aboutie.

Le 403 le plus courant est le quota anonyme de l'API GitHub — 60 requêtes par heure et par adresse IP, partagées avec tout ce qui sort de la même adresse. Il est reconnu comme tel (403/429 + x-ratelimit-remaining: 0), annoncé avec l'heure de remise à zéro que GitHub fournit, et respecté : insister avant cette heure n'essuierait que le même refus.

Vérifications

Instance réelle, API GitHub simulée pour provoquer chaque réponse :

Situation État affiché Version publiée Message
Réponse normale outdated abcdef1
Quota épuisé (403 + x-ratelimit-remaining: 0) outdated conservé abcdef1 conservé « Quota de l'API GitHub épuisé pour cette adresse IP… Prochaine vérification possible à 10h40. »
Nouvelle demande pendant le blocage inchangé inchangé idem, sans requête sortante
Panne réseau up-to-date conservé conservé « Vérification impossible (réseau indisponible ?) »
Retour du réseau up-to-date conservé message effacé

Avant ce correctif, les trois lignes d'échec affichaient « État inconnu » et « — ».

tsc --noEmit, npm run lint et next build passent.


Generated by Claude Code

Deux défauts distincts derrière le même écran.

Le workflow de publication annulait la construction en cours à chaque nouvelle
fusion, comme le fait la vérification des PR. Deux fusions séparées de moins
que la durée d'une construction suffisaient donc à tuer la publication
précédente avant qu'elle n'ait poussé son image : `latest` restait plusieurs
versions en arrière et l'`updater`, qui ne suit que `latest`, avec elle. Les
publications attendent désormais leur tour au lieu de s'annuler ; un commit
intermédiaire peut être sauté, mais il est un ancêtre de celui qui sera publié.

Côté application, un échec de vérification effaçait la dernière réponse connue
de GitHub : un seul 403 faisait retomber l'écran sur « État inconnu » alors
qu'il savait encore quelle version était publiée. La réponse connue est
maintenant conservée, l'erreur s'affiche à côté et non à la place, et la date
affichée est celle de la dernière vérification réellement aboutie.

Le 403 le plus courant est le quota anonyme de l'API GitHub : 60 requêtes par
heure et par adresse IP, partagées avec tout ce qui sort de la même adresse. Il
est désormais reconnu comme tel, annoncé avec l'heure de remise à zéro fournie
par GitHub, et respecté — insister avant cette heure ne ferait qu'essuyer le
même refus.

Vérifié sur une instance réelle : réponse normale, quota épuisé, demande forcée
pendant le blocage, panne réseau puis retour. Dans tous les cas d'échec, l'état
et la révision publiée restent affichés avec la raison de l'échec.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014SfQYBU4xXTeSEHKhHQXdD
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants