First /add can fail when tiktoken downloads o200k_base at runtime

Cerrado
  • ¿Algo no está bien?
#277 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@rendigua2025-gif ya está trabajando en esto.

Desde el 11/6/2026.

  • #285 de @rendigua2025-gif — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
python
Área
backend

Línea de trabajo

Start by tracing the /add request to where tiktoken.get_encoding("o200k_base") is initialized, and review the cold-start failure evidence in this issue. Compare the proposed approaches with open pull request #285 before choosing a direction. Done means cold /add no longer returns a generic 500 when tokenizer asset fetching fails, with behavior verified in an isolated restart/cold-start test.

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

Descripción

Summary

The first /add request can fail with HTTP 500 if tokenizer initialization tries to download o200k_base.tiktoken at runtime and that network request fails.

In an isolated restart/cold-start test, the failure happened before any business write was committed. After prewarming the tokenizer cache with tiktoken.get_encoding("o200k_base"), the same test shape worked with a new memory root/session.

Why this matters

This makes a fresh EverOS service depend on runtime network access to an external tokenizer asset during the first memory write. If that download fails, users see a generic /add 500 even though the memory pipeline itself has not started writing data yet.

This is especially surprising for Docker/Linux isolated tests and server deployments where outbound network/TLS behavior may vary.

Observed evidence

First cold /add:

/add -> HTTP 500

Failure occurred before writes:

unprocessed_buffer: 0
memcell: 0
conversation_status: 0
md_change_state: 0
Markdown marker: none
search result count: 0

Traceback shape:

tiktoken_ext/openai_public.py: o200k_base
tiktoken/load.py: read_file_cached
requests.get("https://openaipublic.blob.core.windows.net/encodings/o200k_base.tiktoken")
SSLError: UNEXPECTED_EOF_WHILE_READING

After tokenizer prewarm:

tiktoken.get_encoding("o200k_base")

A new memory root/session completed successfully, and restart recovery worked as expected.

Expected behavior

EverOS could make this cold-start dependency more explicit and reliable. Possible options:

  • Prewarm tokenizer assets during everos init or server startup.
  • Document that first use may download tokenizer assets and how to pre-cache them.
  • Fail startup or preflight checks with a clear tokenizer/cache error instead of returning a generic /add 500.
  • Avoid runtime network fetches in the request path where possible.
  • Provide an offline/cache configuration path for Docker/server deployments.

Environment

EverOS: 1.0.0 source checkout
Runtime: Docker Linux runtime
Python: 3.12
Data: synthetic sample only

No real user memory or secrets were used.

Lenguaje dominante
Python
Estrellas
13.3k
Forks
926
Merge medio
21 h 34 min
PR fusionados (30 d)
36

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 EverMind-AI/EverOS

Todos los issues de EverMind-AI/EverOS

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.