fix: extract toHostPath helper to fix inconsistent path rewrite fallback#104
Conversation
There was a problem hiding this comment.
The toHostPath extraction is exactly right — fixes the fallback inconsistency and adds uniform warnings. Clean change, good call.
Two things worth looking at before merging:
1. Scope: this PR does more than the title says
Beyond the path rewrite fix, the diff also adds:
getContainerEnv(new method)- Model-change detection +
docker commit+ container recreation logic mkdirSyncforarchived/mailbox directory
None of those are related to the path rewrite. They could have been a separate PR. Not a blocker, but worth noting for the record — reviewers may miss things when the scope is wider than the title suggests.
2. Silent getContainerEnv failure → spurious model mismatch
private getContainerEnv(cname: string, key: string): string {
try {
const out = execSync(...);
...
} catch {}
return ''; // ← silently returns empty on any failure
}If docker inspect fails transiently (Docker daemon hiccup, timeout, etc.), getContainerEnv returns ''. If wantModel is non-empty (e.g. 'claude-3-7-sonnet-20250219'), the comparison '' !== 'claude-...' is true — the supervisor thinks the model changed, runs docker commit (up to 120s), then recreates the container.
On the next start, docker inspect might fail again → same path → repeated 2-minute stalls every restart.
Suggested fix: log a warning when inspect fails rather than silently returning '', so at least it's visible:
} catch (err) {
console.warn(`[supervisor] getContainerEnv(${cname}, ${key}) failed, assuming empty`, err);
return '';
}The silent-empty return is also why containerModel === '' when the container genuinely has no LLM_MODEL set — that case works correctly. The problem is you can't distinguish "container has no model" from "inspect failed". A warning doesn't fix the logic gap but at least surfaces the failure.
There was a problem hiding this comment.
Nice cleanup. One tiny edge: toHostPath warns whenever the replacement is a no‑op, but if HOST_PATH ends up equal to OPENSEED_HOME (default when OPENSEED_HOST_PATH unset) then any Docker run will warn even though the substitution was “successful”. Might be worth warning only when !p.includes(OPENSEED_HOME) (or when OPENSEED_HOME === HOST_PATH) to avoid noisy false positives.
Replaces inline path rewrite that used a different fallback ('/data')
than the module-level OPENSEED_HOME (~/.openseed). When neither env var
is set, the string replacement silently fails, producing broken bind
mounts.
The toHostPath helper:
- Uses the module-level OPENSEED_HOME constant (consistent fallback)
- Warns when substitution is a no-op (broken mount detection)
- Eliminates the duplicated env-var evaluation
Closes openseed-dev#102
15bcc8f to
59ba710
Compare
|
Rebased on current main and narrowed scope to just the The diff is now +11/-3, single file. The core fix is the same: uses the module-level |
Problem
createContainerinsupervisor.tsrewrites container-internal paths to host paths for Docker bind mounts. The same logic was duplicated 3× with two concrete bugs (see #102):1. Inconsistent fallback path. The inline code used
'/data'as fallback when env vars were unset, but the module-levelOPENSEED_HOMEfalls back to~/.openseed. When neitherOPENSEED_HOMEnorITSALIVE_HOMEis set, the string replacement silently fails — no match → bind mount uses the internal container path on the host (likely wrong or nonexistent).2. Missing warnings. Only
hostBoardDirhad a no-op substitution warning.hostDirandhostMailboxsilently produced broken paths.Fix
Extract a
toHostPath(p: string)helper that:OPENSEED_HOMEconstant (same fallback as everything else)Net: +14 / -13 lines, single file change.
Closes #102