Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Cloudflare: purges are now queued, paced and retried (template #115)

Chiusa Adatta ai principianti
#142 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
1/5
Tempo stimato
1-3 ore
Idoneità per principianti
90/100
Tipo di issue
Documentazione
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
markdown
Ambito
documentation

Direzione di ricerca

Aggiorna content/6.deployment/6.cloudflare.md (Rate limits, messaggi di log degli errori di purge, nuova tabella delle impostazioni) e la tabella CDN Purging in content/6.deployment/3.ci-cd.md, usando il commit del template collegato 37afcb1 come fonte di verità per il nuovo comportamento di coda/retry e le quattro variabili CLOUDFLARE_PURGE_*. È completato quando le affermazioni obsolete su 'no retry' sono sparite, i quattro nuovi messaggi di log sono citati accuratamente e entrambe le pagine elencano le variabili con il consiglio sul account condiviso.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Template commit 37afcb1 (components-web-app#115) changes how the patched Souin sends purges to Cloudflare. Several statements in the docs are now out of date.

What changed

  • Purges are queued in one sender per zone instead of sent straight away. Tags are deduplicated and sent up to 100 per request (previously 30), paced by a token bucket sized for the Cloudflare plan.
  • A 429 is retried after Retry-After. 5xx and network errors are retried too. Other failures, such as a bad token (401/403), are logged and dropped.
  • A backlog that can't be sent within a minute is replaced by one purge everything. A full flush replaces anything queued.
  • New optional settings (php container env; GitLab/GitHub variables reach helm through k8s.sh, and compose passes them through when set):
Variable Default Notes
CLOUDFLARE_PURGE_PLAN free free, pro, business or enterprise: sets the rate and burst to that plan's purge limits
CLOUDFLARE_PURGE_REQUESTS from the plan Requests per CLOUDFLARE_PURGE_WINDOW
CLOUDFLARE_PURGE_WINDOW from the plan A Go duration, e.g. 1m, 1s
CLOUDFLARE_PURGE_BURST from the plan Requests that can be sent at once

Each php process has its own bucket, but the limit is per account. When staging and production, or several sites, share an account, set a lower rate on each (e.g. on Free, CLOUDFLARE_PURGE_REQUESTS=2, CLOUDFLARE_PURGE_BURST=10 for each of two sites). A 429 from a neighbour is still retried, so going over costs a delay, not a stale page.

Limits: the queue is in memory, so a pod crash loses purges still queued (a deploy purges everything anyway). Edge purges can arrive later than the save while the bucket refills.

Pages to update

  • content/6.deployment/6.cloudflare.md
    • Rate limits: "Souin doesn't retry, so each refused purge leaves its pages stale" is no longer true. Describe the queue, the retry and the coalescing into purge everything.
    • The Pro-or-above recommendation can soften: Free no longer loses purges. It still delays them under heavy editing, and coalescing turns them into whole-zone purges, which costs edge hit rate.
    • Purge failures are logged: the messages are now Cloudflare purge of N tags rate limited, will retry in …, … failed with status N, will retry: … (5xx), … failed with status N: … [tags] (dropped), and Cloudflare purge: N tags queued, more than the purge limit can send soon, so purging everything instead.
    • Add the settings above, with the advice for shared accounts.
  • content/6.deployment/3.ci-cd.md, CDN Purging table: add the four variables.
Lingua principale
Vue
Stelle
0
Fork
0
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di components-web-app/docs

Tutte le issue di components-web-app/docs

Issue simili

Altre issue su Documentation

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.