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

Memory leak: the shared `validation_aborted_error` keeps every traceback it is raised through

Abierto Apto para principiantes
  • ¿Algo no está bien?
#287 0 comentarios 0 reacciones 0 asignados Ver en GitHub

@Fire162 ya está trabajando en esto.

Desde el 24/10/2026.

  • #288 de @Fire162 — abierto

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
78/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
python
Área
api, backend

Línea de trabajo

Empieza en graphql/validation/validate.py, donde se lanza el validation_aborted_error compartido, y revisa cómo validate() gestiona el momento en que se alcanza max_errors. La reproducción del issue muestra el traceback y el crecimiento de memoria; ejecútala antes y después del cambio para confirmar que las llamadas repetidas ya no retienen tracebacks cada vez mayores. Se considera terminado cuando cada llamada de validación lanza su propio error y el crecimiento de memoria se estabiliza.

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

Descripción

Since aab6d50 (first released in 3.3.0a3), validate() raises one shared, module-level ValidationAbortedError once max_errors is reached. When an existing exception object is raised again, Python adds the new frames to its existing __traceback__. So every aborted validation lengthens the singleton's traceback, and that traceback keeps those frames, and with them each request's document and validation context, alive for the life of the process.

Any client can trigger this by sending a query with more than 100 validation errors. In a long-running server, memory grows with every such request.

Reproduction (graphql-core 3.3.0, CPython 3.12):

import gc, tracemalloc
from graphql import build_schema, parse, validate
from graphql.validation.validate import validation_aborted_error

schema = build_schema("type Query { a: Int }")
document = parse("{ " + " ".join(f"f{i}" for i in range(101)) + " }")

tracemalloc.start()
validate(schema, document)
gc.collect()
base = tracemalloc.get_traced_memory()[0]
for _ in range(200):
    validate(schema, document)
gc.collect()
tb, n = validation_aborted_error.__traceback__, 0
while tb:
    n, tb = n + 1, tb.tb_next
print(n, (tracemalloc.get_traced_memory()[0] - base) // 1024, "KiB")

Result:

Repeated calls Traceback entries Memory retained
1 16 147 KiB
10 88 1,389 KiB
100 808 12,549 KiB
200 1,608 24,820 KiB

That is about 124 KiB more per aborted validation, with no upper limit. The same script on 3.2.13, which creates a new error each time, levels off at about 259 KiB.

Suggested fix: create a new ValidationAbortedError on each validate() call instead of reusing the module-level instance. Clearing __traceback__ before each raise would also work, but every caller's error list would still share one mutable error object.

Lenguaje dominante
Python
Estrellas
532
Forks
154
Merge medio
1 d 9 h
PR fusionados (30 d)
6

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

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 graphql-python/graphql-core

Todos los issues de graphql-python/graphql-core

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.