Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Cerrado Apto para principiantes
#142 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
1/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
90/100
Tipo de issue
Documentación
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
markdown

Línea de trabajo

Actualiza content/6.deployment/6.cloudflare.md (Rate limits, mensajes de registro de errores de purga, nueva tabla de configuraciones) y la tabla CDN Purging de content/6.deployment/3.ci-cd.md, usando el commit de plantilla enlazado 37afcb1 como fuente de verdad para el nuevo comportamiento de cola/reintentos y las cuatro variables CLOUDFLARE_PURGE_*. Se considera terminado cuando desaparezcan las afirmaciones obsoletas de 'no retry', los cuatro nuevos mensajes de registro se citen con exactitud y ambas páginas enumeren las variables con el consejo sobre la cuenta compartida.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Vue
Estrellas
0
Forks
0
Métricas de merge de PR
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de components-web-app/docs

Todos los issues de components-web-app/docs

Issues similares

Más issues de Documentation

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.