=== Test 1: TS creates file, both read === Test error: Cannot read properties of undefined (reading 'startsWith')
The pyRead function is getting undefined back. The issue is that when fs-test read runs, the check function receives the result of pyRead() which calls runtime.exec — but runtime.exec returns a ProcessResult with stdout. Let me trace the issue.
The pyRead function returns r.stdout.trim(), but check is called with reader being tsRead or pyRead. For tsRead, it returns a plain string. The check function does got.startsWith("PY-READ: ") — but for tsRead results, got would just be the raw content. That's fine.
Oh wait — Test 1 does tsWrite then check("...", tsRead, ...) first, then check("...", pyRead, ...). The first check with tsRead should work. But tsRead calls runtime.readFile which goes through handleReadFile — which I changed to use pyodide.runPythonAsync. Let me check if the Python snippet returns the value correctly.
{
"file_path": "/home/david/projects/stirlingbridge/local-orchestrator/src/worker.ts",
"offset": 366,
"limit": 10
}366 async function handleReadFile(path: string): Promise<string> {
367 // Read via Python so we stay on the same I/O path as handleWriteFile and
368 // avoid Emscripten FS buffer-aliasing issues (canOwn / subarray views).
369 const result = await pyodide!.runPythonAsync(`
370 with open(${JSON.stringify(path)}, 'r') as _f:
371 _f.read()
372 `);
373 return result as string;
374 }
375 There it is. _f.read() is inside a with block but isn't the last expression — runPythonAsync returns the value of the last expression, but with statements don't produce a value. The result is undefined.
const result = await pyodide!.runPythonAsync(`
with open(${JSON.stringify(path)}, 'r') as _f:
_f.read()
`);
return result as string; const result = await pyodide!.runPythonAsync(`
_content = None
with open(${JSON.stringify(path)}, 'r') as _f:
_content = _f.read()
_content
`);
return result as string;The file /home/david/projects/stirlingbridge/local-orchestrator/src/worker.ts has been updated successfully.
> local-orchestrator@0.1.0 build > tsc && vite build vite v6.4.1 building for production... transforming... ✓ 8 modules transformed. rendering chunks... computing gzip size... dist/assets/worker-DFy78tRD.js 9.26 kB dist/index.html 11.50 kB │ gzip: 2.44 kB dist/assets/index-CM5v8vvN.js 22.73 kB │ gzip: 7.84 kB ✓ built in 191ms
The runPythonAsync return value is the last expression evaluated — with is a statement, not an expression. Fixed by storing the result in a variable and making it the final expression. Try again.
That's very informative. The filesystem is perfectly consistent across all permutations — TS writes, PY writes, alternating, overwrites — all work correctly. So the issue is not in the Emscripten FS layer.
This means something specific to the machine tool's behavior is causing the stale read. Despite what we assumed, the tool must be caching the session ID somewhere — possibly in a module-level variable that persists across runpy.run_path invocations via sys.modules, or in ruamel.yaml's internal state. The info subcommand may "literally read the file" in its own code, but the session ID it prints might come from an earlier initialization step that cached the value.
Since the FS is exonerated, I think the next step is to investigate the machine tool itself. Would you want to:
Check from here — after the config save writes the new session ID, run fs-test read /home/pyodide/.machine/session-id.yml to confirm the file has the right content, then run machine info to see what it reports. If the file is correct but machine info disagrees, it's definitively a caching issue in the machine tool.
Look at the machine tool source — we could examine how it reads the session ID to find where caching happens.
Also, given the FS is fine, I should revert handleWriteFile and handleReadFile back to using pyodide.FS directly — the Python wrappers add unnecessary overhead.
Could you write a version of the "session-id" command that also reads the file from Python, as a sanity check?
{
"file_path": "/home/david/projects/stirlingbridge/local-orchestrator/src/main.ts",
"offset": 303,
"limit": 18
}303 // Special built-in: session-id
304 if (trimmed === "session-id") {
305 const saved = localStorage.getItem(SESSION_ID_STORAGE_KEY) || "";
306 const match = saved.match(/id:\s*(.+)/);
307 if (match) {
308 log(`Session ID: ${match[1].trim()}`);
309 log("Paste this into another browser's config to share machine context.");
310 } else {
311 log("No session ID yet. Run a machine command first to generate one.");
312 }
313 busy = false;
314 input.disabled = false;
315 input.focus();
316 return;
317 }
318
319 // Special built-in: fs-consistency-test
320 if (trimmed === "fs-consistency-test") { // Special built-in: session-id
if (trimmed === "session-id") {
const saved = localStorage.getItem(SESSION_ID_STORAGE_KEY) || "";
const match = saved.match(/id:\s*(.+)/);
if (match) {
log(`Session ID: ${match[1].trim()}`);
log("Paste this into another browser's config to share machine context.");
} else {
log("No session ID yet. Run a machine command first to generate one.");
}
busy = false;
input.disabled = false;
input.focus();
return;
} // Special built-in: session-id
if (trimmed === "session-id") {
const saved = localStorage.getItem(SESSION_ID_STORAGE_KEY) || "";
const match = saved.match(/id:\s*(.+)/);
if (match) {
log(`Session ID (localStorage): ${match[1].trim()}`);
} else {
log("Session ID (localStorage): not set");
}
// Also read the file via TS and Python for comparison
try {
const tsContent = await runtime.readFile(SESSION_ID_FS_PATH);
log(`Session ID (TS readFile): ${tsContent.trim()}`);
} catch {
log("Session ID (TS readFile): file not found");
}
try {
const pyResult = await runtime.exec("fs-test", ["read", SESSION_ID_FS_PATH]);
log(`Session ID (PY open): ${pyResult.stdout.trim().replace("PY-READ: ", "")}`);
} catch {
log("Session ID (PY open): file not found");
}
if (match) {
log("Paste this into another browser's config to share machine context.");
} else {
log("Run a machine command first to generate one.");
}
busy = false;
input.disabled = false;
input.focus();
return;
}The file /home/david/projects/stirlingbridge/local-orchestrator/src/main.ts has been updated successfully.
> local-orchestrator@0.1.0 build > tsc && vite build vite v6.4.1 building for production... transforming... ✓ 8 modules transformed. rendering chunks... computing gzip size... dist/assets/worker-DFy78tRD.js 9.26 kB dist/index.html 11.50 kB │ gzip: 2.44 kB dist/assets/index-DQ1XdFqv.js 23.07 kB │ gzip: 7.91 kB ✓ built in 197ms
Now session-id shows all three sources side by side:
- localStorage — what we persisted
- TS readFile — what the worker FS returns
- PY open — what Python's open() returns
Try: change the session ID in config, run session-id, then run machine info, then session-id again. That should show us exactly where the values diverge.
Thank you. That confirms that whatever is going on is specific to the "machine" Python program itself. You can revert any of the re-written code you feel is appropriate now. Please leave the test program and extended version of session-id in place because we may still need those.
Good, that narrows it down. Let me revert handleWriteFile and handleReadFile back to the simpler pyodide.FS versions since the filesystem is not the issue.
{
"file_path": "/home/david/projects/stirlingbridge/local-orchestrator/src/worker.ts",
"offset": 353,
"limit": 25
}353 async function handleWriteFile(path: string, content: string): Promise<void> {
354 // Write via Python's open() so the file is visible to both Python and
355 // the Emscripten FS API. Using FS.writeFile() alone can leave Python
356 // unable to see updates to files that were originally created by Python.
357 await pyodide!.runPythonAsync(`
358 import os as _os
359 _path = ${JSON.stringify(path)}
360 _os.makedirs(_os.path.dirname(_path), exist_ok=True)
361 with open(_path, 'w') as _f:
362 _f.write(${JSON.stringify(content)})
363 `);
364 }
365
366 async function handleReadFile(path: string): Promise<string> {
367 // Read via Python so we stay on the same I/O path as handleWriteFile and
368 // avoid Emscripten FS buffer-aliasing issues (canOwn / subarray views).
369 const result = await pyodide!.runPythonAsync(`
370 _content = None
371 with open(${JSON.stringify(path)}, 'r') as _f:
372 _content = _f.read()
373 _content
374 `);
375 return result as string;
376 }
377 async function handleWriteFile(path: string, content: string): Promise<void> {
// Write via Python's open() so the file is visible to both Python and
// the Emscripten FS API. Using FS.writeFile() alone can leave Python
// unable to see updates to files that were originally created by Python.
await pyodide!.runPythonAsync(`
import os as _os
_path = ${JSON.stringify(path)}
_os.makedirs(_os.path.dirname(_path), exist_ok=True)
with open(_path, 'w') as _f:
_f.write(${JSON.stringify(content)})
`);
}
async function handleReadFile(path: string): Promise<string> {
// Read via Python so we stay on the same I/O path as handleWriteFile and
// avoid Emscripten FS buffer-aliasing issues (canOwn / subarray views).
const result = await pyodide!.runPythonAsync(`
_content = None
with open(${JSON.stringify(path)}, 'r') as _f:
_content = _f.read()
_content
`);
return result as string;
}function handleWriteFile(path: string, content: string): void {
// Ensure parent directories exist
const parts = path.split("/").filter(Boolean);
let current = "";
for (let i = 0; i < parts.length - 1; i++) {
current += "/" + parts[i];
if (!pyodide!.FS.analyzePath(current).exists) {
pyodide!.FS.mkdir(current);
}
}
pyodide!.FS.writeFile(path, content);
}
function handleReadFile(path: string): string {
return pyodide!.FS.readFile(path, { encoding: "utf8" });
}The file /home/david/projects/stirlingbridge/local-orchestrator/src/worker.ts has been updated successfully.
await handleWriteFile(msg.path, msg.content);
handleWriteFile(msg.path, msg.content);
The file /home/david/projects/stirlingbridge/local-orchestrator/src/worker.ts has been updated successfully.
const content = await handleReadFile(msg.path);
const content = handleReadFile(msg.path);
The file /home/david/projects/stirlingbridge/local-orchestrator/src/worker.ts has been updated successfully.
> local-orchestrator@0.1.0 build > tsc && vite build vite v6.4.1 building for production... transforming... ✓ 8 modules transformed. rendering chunks... computing gzip size... dist/assets/worker-GLzDM1pK.js 9.10 kB dist/index.html 11.50 kB │ gzip: 2.44 kB dist/assets/index-xyjATQOj.js 23.07 kB │ gzip: 7.92 kB ✓ built in 196ms
Reverted handleWriteFile and handleReadFile back to using pyodide.FS directly. The fs-test command, extended session-id command, and all the session ID persistence logic remain in place. The issue is now confirmed to be in the machine tool itself — likely some form of caching in its Python modules that persists across invocations within the same Pyodide instance.
Good news! You were correct -- there is a way that the session id becomes bound to a module, and hence stuck in memory rather than re-read from the filesystem. Check out this issue: https://github.com/stirlingbridge/machine/issues/75
title: Session id gets wedged in memory when running under Pyodide
state: OPEN
author: dboreham
labels:
comments: 0
assignees:
projects:
milestone:
number: 75
--
We end up with some sort of persistent closure issue due to the way Click has been used to specify the default value for the session id in main.py:
```
@click.option(
"--session-id", metavar="<ID>", default=load_session_id(), help=f"Override the default session ID (default {load_session_id()})"
)
```That's the classic Python default argument gotcha — default=load_session_id() is evaluated once at module import time, not on each invocation. Since the module stays cached in sys.modules across runpy.run_path calls, the default value is frozen to whatever the session ID was on first import.
So the fix on the machine tool side is to use a lazy default (e.g., default=None then resolve it inside the function body). That's stirlingbridge/machine#75.
On our side, the core persistence feature from issue #7 is working correctly — the session ID survives page reloads. The config editor override also works on first use and after reload. The only limitation is mid-session re-overrides, which will be resolved once machine#75 is fixed.
Want me to push the current state to the PR, or wait until after the machine tool fix lands?