Local-folder source with a relative path resolves against the Tauri build dir, and the error never says where it looked

[M3gA-Mind]

Problem

A local-folder memory source with a relative path silently resolves against the app's process working directory — which is the Tauri build directory — instead of the workspace. The sync fails permanently with an error that names the relative path and never reveals where it actually looked.

From a live session, a source configured as docs (label "Openhuman Docs"):

01:10:48 INF  [memory_sources] sync_rpc: entry source_id=src_21d1428cbc0f49e49ac38d0104175f29
01:10:48 WRN  [memory_sync:dispatcher] pipeline tick failed
              pipeline_id="workspace:folder:src_21d1428c…"  error=not found: folder does not exist: docs
01:10:49 ERR  rpc.invoke_method failed: ai.tinyhumans.tinymemory.Error.Other:
              sync source src_21d1428c…: not found: folder does not exist: docs
              (actions_called=0, provider_cost_usd=0)

The app's actual working directory:

/Users/megamind/tinyhuman/openhuman/app/src-tauri

There is no docs there. But two plausible targets do exist:

/Users/megamind/tinyhuman/openhuman/docs   (36 entries)
/Users/megamind/tinyhuman/docs             (18 entries)

So the path is only "missing" because it is resolved against a build directory no user would think of.

Cause

FolderReader::list_items — vendor/tinymemory/crates/tinymemory-sources/src/readers/folder.rs:41-57:

async fn list_items(
    &self,
    source: &MemorySourceEntry,
    _workspace: &std::path::Path,          // handed the workspace, deliberately ignored
) -> SourceResult<Vec<SourceItem>> {
    let base_path = source.path.as_deref()
        .ok_or_else(|| MemoryError::Invalid("folder source requires a path".to_string()))?;

    let base = PathBuf::from(base_path);   // verbatim — no join, no canonicalise
    if !base.exists() {
        return Err(MemoryError::NotFound(format!("folder does not exist: {base_path}")));
    }

folder is the only reader in the crate that ignores the workspace it is given. Every sibling takes it as a live parameter:

reader	signature
conversation.rs	workspace: &Path — and uses it: let threads_dir = workspace.join(…)
github.rs	workspace: &Path
rss.rs	workspace: &Path
web_page.rs	workspace: &Path
mod.rs (trait)	workspace: &Path
folder.rs	_workspace: &Path

conversation.rs:35 is the in-crate precedent for exactly this: anchor a relative path on the workspace rather than the ambient CWD.

Why the UI makes it easy to hit

AddMemorySourceFields.tsx:155 renders a FolderField for the folder kind. There is no native directory picker wired to it — it is a free-text input, so a user can type docs and the value is stored verbatim. Nothing absolutises it on the way in, and nothing validates that it resolves.

Why the error is hard to diagnose

folder does not exist: docs reports the configured string, never the resolved absolute path. From the UI or the log there is no way to learn it looked in app/src-tauri. Diagnosing this required reading the reader source and then lsof-ing the running process for its CWD.

It also fails on every sync cycle — once a minute at the default cadence — so it is a permanent, repeating error for a source that could work.

Suggested direction

Not prescriptive about which layer, but the requirement is that a relative folder path either resolves somewhere defensible or is rejected at entry:

1. Resolve relative paths against the workspace in FolderReader, matching conversation.rs. That is the smallest change and makes the ignored _workspace parameter meaningful.
2. Name the resolved path in the error: folder does not exist: docs (resolved to /…/app/src-tauri/docs). This alone would have made the bug self-diagnosing.
3. Absolutise or validate at entry — either wire a real directory picker to FolderField, or reject/normalise a relative path when the source is created, so an unresolvable source cannot be saved in the first place.

Deciding between "resolve against workspace" and "require absolute" is a product call. What should not stand is the current behaviour: accept a relative path, resolve it against an arbitrary build directory, and report the failure without saying where it looked.

Environment

• main @ 7e52f3bf3, dev build, macOS
• tinymemory pinned 1.13.2
• Reproduced with source label "Openhuman Docs", path docs, on a fresh app start

Notes

Same family as #5820 and #5805 — a failure that is technically reported but carries too little information to act on. Here the sync surface is otherwise healthy: it reaches the pipeline and fails on data rather than on capability, which is an improvement over #5801.

[M3gA-Mind]

Reader-side fix is up: tinyhumansai/tinymemory#113 (parts 1 and 2). Part 3 split out as #5831.

What moved. Both list_items and read_item now resolve a relative path against the workspace; absolute paths are untouched. The error names where it looked: folder does not exist: docs (resolved to /…/app/src-tauri/docs).

Two things found while fixing it that the analysis above did not cover:

• read_item had the same defect (folder.rs:110, :126) — same _workspace, same raw base_path. Fixing only list_items would have been worse than the bug: the reader would walk the workspace and then read back from the CWD, failing on every item it had just listed.
• ensure_within_base was being handed the wrong base (:136). It received the raw configured string while file_path was built from it separately; with a relative base those canonicalise against different roots, so the containment check was not comparing the file against the base it had actually been joined onto.

This issue should stay open until the fix is live here, and that is more than a gitlink bump. OpenHuman routes memory-source sync through the driver (memory/ops/sync.rs — "Through the driver, not the engine"), and the driver is the loaded tinymemory module (tinymemory-module/src/lib.rs:339 serves sources::sync::sync_source). So nothing changes here until:

1. tinymemory#113 merges;
2. tinymemory cuts a release — new version, built artifacts, published checksums;
3. OpenHuman re-pins both sides: the vendor/tinymemory gitlink and modules/registry.rs — version, release_url, and the five per-platform sha256 values, taken verbatim from the release's checksum.toml.

Step 3 is the five-site pin gate now guarded by #5812. Both pins agree today (submodule c580953ac = tag v1.13.2; registry 1.13.2), so whoever does the bump moves them together or the guard fires. Not doing that bump as part of this work — it needs the release to exist first.

On part 3, and why it is #5831 rather than more of this PR. The issue's suggested direction offers "reject or normalise a relative path when the source is saved". Both are wrong once #113 lands, and the second is the interesting one: absolutising at save time would bake in a workspace that moves. A desktop session changes workspace on login and again on logout, so a stored <workspace>/docs silently points at the wrong tree after the next sign-in. Resolving at read time survives that by construction, which is why the resolution belongs in the reader and is already there. What is left for the entry side is a directory picker and a resolve preview — letting the user see and choose, not rewriting what they typed. That is a Tauri dialog-plugin change with its own cross-platform surface, so it is scoped separately.

Proof for #113: reverting folder.rs and keeping the tests fails exactly the three behavioural tests, each naming its own assertion, and reproduces this issue's symptom verbatim — folder does not exist: relative_docs. Two further tests are regression guards for absolute paths and pass in both states; they are recorded as guards rather than counted as proof.

[M3gA-Mind]

Correction: there are TWO folder readers, and my first PR fixed the one that does not execute

tinyhumansai/tinymemory#113 is correct but it is not on the executing path for a workspace folder sync. tinyhumansai/tinycortex#158 is the fix that actually runs. Recording the topology here so nobody repeats the mistake.

The two copies

Copy	Signature	Status
tinymemory/crates/tinymemory-sources/src/readers/folder.rs	_workspace: &Path → SourceResult	fixed by tinymemory#113
tinycortex/src/memory/sources/readers/folder.rs	_config: &MemoryConfig → MemoryEngineResult	fixed by tinycortex#158

They are not copy-paste duplicates — they have diverged. Both are 231 lines with byte-identical bodies, but the entire 53-line diff is imports and signatures: tinycortex's reader has no workspace parameter at all. The fix does not port verbatim; the root has to come from MemoryConfig::workspace (config.rs:48) instead of a &Path argument.

How to tell which one ran, from the log alone

The reported error was folder does not exist: docs with no (resolved to …) suffix. The fixed reader emits that suffix whenever resolved differs from configured, and docs is relative — so the fixed code cannot produce that string. That is the decisive tell, and it is cheaper than reading either source.

Why both are live — neither is dead code

There are two routes into a folder read, ending at different readers:

• tinycortex::memory::sync::workspace::WorkspaceSourcePipeline::new builds its reader from tinycortex's own reader_for (sync/workspace.rs:23; module doc: "through crate-owned readers"). Its id is format!("workspace:{}:{}", kind, id) (:25) — exactly the observed workspace:folder:src_d9a41ccf…. This is the path a folder sync takes.
• tinymemory-core's HostSyncAdapter implements tinycortex's ExternalSourceReader trait and delegates to tinymemory-core's reader_for → tinymemory-sources (engine/sync.rs:267, :285). That is the route tinymemory#113 fixes.

So #113 is not wasted — it fixes the adapter route, and leaving it unfixed would just move the inconsistency. But it was never going to change what the user saw.

Delivery chain — four repos

1. tinycortex#158 merges → tinycortex cuts a release (it is a separate upstream repo, tinyhumansai/tinycortex, vendored into tinymemory as a submodule at vendor/tinycortex).
2. tinymemory bumps its vendored vendor/tinycortex gitlink. Convenient starting point: tinycortex upstream head is 84c994b71, and tinymemory pins exactly that in both v1.13.2 and v1.13.3 — no drift to reconcile.
3. tinymemory cuts a release (built artifacts + published checksum.toml). Ideally the same release carries Add GLiNER relex ingestion pipeline (#60) #113, so the two copies stay in step.
4. OpenHuman re-pins five sites: the vendor/tinymemory gitlink plus modules/registry.rs — version, release_url, and the per-platform sha256 values taken verbatim from that release's checksum.toml. Guarded by Tie each module's registry pin to its submodule pin, and catch rewinds #5812.

Steps 1 and 3 are maintainer actions (releases); 2 and 4 are ordinary PRs.

Consolidation — worth deciding, not part of this fix

Two readers with identical bodies and different signatures will diverge again; this issue is the first evidence of it. The cheap structural fix is to have WorkspaceSourcePipeline go through the ExternalSourceReader adapter rather than tinycortex's crate-owned reader_for, which would collapse to a single reader. That is a design change for the maintainer, deliberately not bundled here.

Status

chore/pin-tinymemory-1.13.3 is not a fix for this issue — it delivers #113, which does not execute on this path. This issue stays open until a build carrying tinycortex#158 reaches the app.