# 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