First /add can fail when tiktoken downloads o200k_base at runtime

クローズ
  • 何か問題がありますか？
#277 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@rendigua2025-gif がすでに取り組んでいます。

2026年6月11日 から。

  • #285 @rendigua2025-gif による — オープン

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
25/100
issue の種類
バグ
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
python
領域
backend

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Python
スター
13.3k
フォーク
926
平均マージ
23時間 31分
マージ済み PR（30日）
26

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

EverMind-AI/EverOS のほかの issue

EverMind-AI/EverOS の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。