mirror of
https://gitverse.ru/kpa39l/memory-os.git
synced 2026-09-28 21:15:02 +00:00
2.4 KiB
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
.envback 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.pycannot 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:
mount | grep s3fs— check if mount is activesystemctl statusfor s3fs — check if automount service is runningsudo journalctl -ufor s3fs — check for errors- Direct HTTP check against
s3.nixg.ru— test S3 endpoint reachability - Verify
passwd-s3fsfile exists and has correct credentials