Memory fails to initialize on a fresh install of `phoenix-os==1.0.0`. Every...

[DarkVertana]

What happened

Memory fails to initialize on a fresh install of phoenix-os==1.0.0. Every
phoenix start aborts with:

Embedding warm-up failed: OperationalError: no such table: memories

The suggested recovery paths don't work — phoenix --embedder fastembed and
phoenix --setup both leave the same error, because neither one creates the
database schema.

Root cause (verified locally): the published 1.0.0 wheel does not include the
SQL migration files. MemoryStore builds its schema by running the .sql files
in phoenix/memory/migrations/, but that directory is absent from the installed
package:

• phoenix.memory.store.MIGRATIONS_DIR.exists() → False
• There are zero .sql files anywhere in the installed phoenix/ package.
• The only CREATE TABLE statement shipped is the _migrations bookkeeping
  table in store.py; the memories table (and the rest of the schema) lives
  only in the un-shipped migration files.

Because no migrations run, connect() creates an empty _migrations table and
nothing else. _check_embedding_dim() then does SELECT embedding FROM memories,
which raises OperationalError: no such table: memories. This is independent of
the embedding backend, which is why switching to fastembed and re-running setup
both fail identically.

Note: I originally hit this right after Ctrl-C'ing the EmbeddingGemma download,
but the cancellation is a red herring — the migrations are missing from the wheel
regardless, so memory could never have initialized with this build.

Expected: on first run, Phoenix creates the memories table (and full schema) and
memory initializes successfully.

How to reproduce

1. pip install phoenix-os==1.0.0 into a fresh venv (Python 3.14).
2. Run phoenix and complete setup (any provider; either embedder).
3. Run phoenix again → it prints
   Embedding warm-up failed: OperationalError: no such table: memories
   and exits. phoenix --embedder fastembed and phoenix --setup do not fix it.

Direct confirmation without the full app:

python -c "from phoenix.memory.store import MIGRATIONS_DIR as m; print(m, m.exists(), list(m.glob('*.sql')) if m.exists() else [])"
# -> .../phoenix/memory/migrations False []

sqlite3 ~/.phoenix/memory.db ".tables"
# -> _migrations        (no 'memories' table)

Environment

• Phoenix version: phoenix-os 1.0.0 (note: phoenix --version is unrecognized;
  version taken from pip show phoenix-os / importlib.metadata)
• Python version: Python 3.14.4
• OS: macOS 26.5.1 (Darwin 25.5.0, build 25F80)
• Model / Provider: google-gla:gemini-2.5-pro (Google Gemini); embedder tried
  with both gemma and fastembed — same failure

Logs

$ phoenix
  Verifying google-gla key...
Loading embedding model...
Embedding warm-up failed: OperationalError: no such table: memories

Memory cannot initialize. Fix with one of:
  phoenix --setup              retry Hugging Face auth for Gemma
  phoenix --embedder fastembed  switch to MiniLM (English-only, no HF auth)

# Diagnostics
$ python -c "from phoenix.memory.store import MIGRATIONS_DIR as m; print(m.exists())"
False

$ find $(python -c "import phoenix,os;print(os.path.dirname(phoenix.__file__))") -name '*.sql'
# (no output — no .sql files shipped)

$ sqlite3 ~/.phoenix/memory.db "SELECT name FROM sqlite_master WHERE type='table'"
_migrations
$ sqlite3 ~/.phoenix/memory.db "SELECT * FROM _migrations"
# (empty — zero migrations applied)

Log directory: /Users/pratikmore/.phoenix/logs

Recent entries:

2026-06-06 15:30:00 INFO phoenix.config.secrets: Secret backend: keyring backend: Keyring
2026-06-06 15:30:00 INFO phoenix.config.secrets: Secrets loaded: 0 from keyring, 0 from fallback file; 11 missing
2026-06-06 15:32:16 INFO phoenix.config.secrets: Secret backend: keyring backend: Keyring
2026-06-06 15:32:16 INFO phoenix.config.secrets: Secrets loaded: 2 from keyring, 0 from fallback file; 9 missing
2026-06-06 15:32:24 INFO phoenix.config.secrets: Secret backend: keyring backend: Keyring
2026-06-06 15:32:24 INFO phoenix.config.secrets: Secrets loaded: 2 from keyring, 0 from fallback file; 9 missing
2026-06-06 15:32:29 INFO phoenix.config.secrets: Secret backend: keyring backend: Keyring
2026-06-06 15:32:29 INFO phoenix.config.secrets: Secrets loaded: 2 from keyring, 0 from fallback file; 9 missing
2026-06-06 15:32:36 INFO phoenix.config.secrets: Secret backend: keyring backend: Keyring
2026-06-06 15:32:36 INFO phoenix.config.secrets: Secrets loaded: 2 from keyring, 0 from fallback file; 9 missing
2026-06-06 15:32:47 INFO phoenix.config.secrets: Secret backend: keyring backend: Keyring
2026-06-06 15:32:47 INFO phoenix.config.secrets: Secrets loaded: 2 from keyring, 0 from fallback file; 9 missing

Extra context

Likely a packaging defect: the phoenix/memory/migrations/*.sql files need to be
declared as package data so they're included in the wheel/sdist (e.g.
[tool.hatch.build.targets.wheel] include, force-include, or a
[tool.setuptools.package-data] / MANIFEST.in entry for *.sql).

Two secondary improvements worth considering:

• _apply_migrations() should fail loudly if MIGRATIONS_DIR is missing or
  contains zero .sql files, instead of silently creating an empty DB that
  surfaces later as a confusing "no such table: memories".
• The "Memory cannot initialize" recovery hint suggests --setup /
  --embedder fastembed, but neither addresses a missing-schema condition; the
  message could distinguish "schema not created" from "embedder/auth failure".