Office archipelago: migrate /hero_foundry/rpc/api/files/<context>/ calls to post-bfc845b foundry API #202

New issue

Open

opened 2026-05-03 18:27:25 +00:00 by zaelgohary · 0 comments

zaelgohary commented

2026-05-03 18:27:25 +00:00

Member

Summary

hero_archipelagos/.../embed/office/src/service.rs:64 OfficeEndpoint::file_url() builds URLs of shape:

{api_host}/hero_foundry/rpc/api/files/{ctx}/{name}

This worked against the old (pre-bfc845b) hero_foundry, which auto-created context directories under a single global WebDAV root. The May 2 bfc845b feat(foundry)!: rename fossil to foundry, per-repo layout refactor removed that behavior:

The new foundry's /api/files/{repo}/{path...} requires {repo} to be a pre-registered foundry repo — it does NOT auto-create
The --allow-dir/--webdav-storage server args were also removed
Old "context"-flavored callers all 404 on the new server

What needs to happen in the office consumer

One of:

Register the {ctx} value (e.g. geomind) as a foundry repo at first use (via a foundry-management RPC), then call /api/files/{repo}/...
Switch to the new /webdav/<reponame>/... route if office's use case is bulk file IO rather than typed-file ops
Some other contract appropriate for the office archipelago — needs design input

Where this surfaced

Internal QA sweep: 156 /hero_foundry/rpc/api/files/<context>/... 404s after deploying a fresh hero_foundry build from current development. Was misdiagnosed initially as a fork divergence (filed + closed at hero_foundry/issues/25); this is the real ticket against the consumer.

Repro

curl -sf -X PUT --data-binary @doc.txt "$HOST/hero_foundry/rpc/api/files/geomind/doc.txt"
# → 404 against post-bfc845b foundry, 200 against pre-bfc845b

Filing for owner input — no patch yet. Tagging zaelgohary.

## Summary `hero_archipelagos/.../embed/office/src/service.rs:64` `OfficeEndpoint::file_url()` builds URLs of shape: ``` {api_host}/hero_foundry/rpc/api/files/{ctx}/{name} ``` This worked against the old (pre-bfc845b) hero_foundry, which auto-created context directories under a single global WebDAV root. The May 2 `bfc845b feat(foundry)!: rename fossil to foundry, per-repo layout` refactor removed that behavior: - The new foundry's `/api/files/{repo}/{path...}` requires **`{repo}` to be a pre-registered foundry repo** — it does NOT auto-create - The `--allow-dir`/`--webdav-storage` server args were also removed - Old "context"-flavored callers all 404 on the new server ## What needs to happen in the office consumer One of: 1. Register the `{ctx}` value (e.g. `geomind`) as a foundry repo at first use (via a foundry-management RPC), then call `/api/files/{repo}/...` 2. Switch to the new `/webdav/<reponame>/...` route if office's use case is bulk file IO rather than typed-file ops 3. Some other contract appropriate for the office archipelago — needs design input ## Where this surfaced Internal QA sweep: 156 `/hero_foundry/rpc/api/files/<context>/...` 404s after deploying a fresh hero_foundry build from current development. Was misdiagnosed initially as a fork divergence (filed + closed at hero_foundry/issues/25); this is the real ticket against the consumer. ## Repro ``` curl -sf -X PUT --data-binary @doc.txt "$HOST/hero_foundry/rpc/api/files/geomind/doc.txt" # → 404 against post-bfc845b foundry, 200 against pre-bfc845b ``` Filing for owner input — no patch yet. Tagging zaelgohary.