Files
memory-os/references/dimension-mismatch-s3fs-blockers.md
2026-09-06 13:51:22 +00:00

2.4 KiB

Dimension Mismatch & s3fs Blockers — 2026-07-16

Issue 1: Qdrant 400 Bad Request (Dimension Mismatch)

Symptom:

[CE-FALLBACK] Qdrant general error (400 Client Error: Bad Request
for url: http://localhost:6333/collections/knowledge_base/points/query),
falling back to lexical.
[CE-FALLBACK] All fallback levels exhausted.

Root cause: The Qdrant collection knowledge_base was created with 768d vectors (nomic-embed-text via Ollama), but .env was later changed to point at Polza.ai with qwen3-embedding-8b (4096d). The context_enhancer.py reads .env and sends 4096d query vectors to a 768d collection — Qdrant rejects with 400.

Cross-check:

# Collection says: 768d
# .env says: 4096d

Resolution options:

  • (a) Change .env back to Ollama nomic-embed-text 768d (local, free, matches collection)
  • (b) Recreate the collection at 4096d (destructive — lose all 683 points)
  • (c) Create a second collection for 4096d, keep the old one

Note: The wiki_continuous_ingest.py worker reads from the same .env — points may also be upserted with wrong dimensions. Also the docker/.env file may differ from the project root .env.

Issue 2: s3fs Obsidian Vault Mount Empty

Symptom:

ls -la /opt/hermes/obsidian-vault/
total 8
drwxr-xr-x 2 estorozhenko estorozhenko 4096 ...
drwxr-xr-x 6 estorozhenko estorozhenko 4096 ...

Only . and .. — the directory exists but is empty.

fstab entry:

s3fs#obsidian /opt/hermes/obsidian-vault fuse _netdev,allow_other,
  passwd_file=/etc/passwd-s3fs,use_cache=/tmp,
  url=https://s3.nixg.ru,endpoint=garage,
  use_path_request_style,sigv4 0 0

This is a Garage S3 bucket mounted via s3fs. The mount point exists but no data is visible.

Impact:

  • sync_obsidian_to_wiki.py cannot sync (no source files)
  • The script has a safety guard: if vault is empty but state has files, it skips deletion (VAULT ПУСТ — пропускаю удаление). This prevents data loss if the mount is temporarily disconnected.
  • C1 (schedule sync) is blocked until mount is restored

Diagnosis steps:

  1. mount | grep s3fs — check if mount is active
  2. systemctl status for s3fs — check if automount service is running
  3. sudo journalctl -u for s3fs — check for errors
  4. Direct HTTP check against s3.nixg.ru — test S3 endpoint reachability
  5. Verify passwd-s3fs file exists and has correct credentials