hero_osis cannot build against published hero_rpc/hero_lib (needs local hero_rpc + hero_lib pushed) #66
Labels
No labels
prio_critical
prio_low
type_bug
type_contact
type_issue
type_lead
type_question
type_story
type_task
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
lhumina_code/hero_osis#66
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
hero_osis currently only builds because of committed local-path
[patch]entries inCargo.tomlthat point at one developer's machine (/Users/despiegk/.cargo/.../hero_lib/crates/weband/Volumes/T7/hero/code/hero_rpc/...). Those paths do not exist anywhere else, so the lab-release CI fails and no one else can build hero_osis from a clean checkout.When the local
[patch]is removed and the deps are pointed at published branches (I tried bothintegrationandmain), three problems surface in order:hero_lib@developmentis missing theherolib_derivecrate (crates/derive), which is required transitively viahero_rpc_osisthenhero_indexer_sdk. Theintegrationandmainbranches both have it;developmentdoes not. This is the error the current CI run actually reports.hero_lifecycle::serve_unixmoved into theservemodule (hero_lifecycle::serve::serve_unix) and now takes a thirdShutdownRxargument.crates/hero_osis_admin/src/main.rs:134still calls the old two-argument root path. This is a small fix and I already have it ready.The real blocker:
hero_osis_serverthen fails with roughly 1100hero_rpc_osis::db::OsisObjecttrait and derive-macro errors against the published hero_rpc on every branch. hero_osis's code matches theOsisObjectcodegen in the local hero_rpc the[patch]points at (/Volumes/T7/hero/code/hero_rpc), not what is published. So hero_osis effectively depends on an unreleased version of hero_rpc.What is needed: please push your local hero_rpc and the matching hero_lib changes (including
herolib_derive) to a shared branch (integrationormain), so hero_osis can depend on published versions instead of local paths. Once that is up, the[patch]block can be removed and the deps pointed at that branch, and the smallserve_unixupdate can land. Happy to do that cleanup once your changes are published.Signed-by: mik-tf mik-tf@noreply.invalid
Progress plus one new finding to record here.
Good news first: the hero_os desktop front end (the WASM shell built from hero_os_app) now builds and runs live on a member instance. The shell is served through the router and the desktop opens in the browser, so the front end side of hero_os is working.
The remaining blocker for hero_os to actually do anything is this issue: its islands call hero_osis, and hero_osis is not reachable. Beyond the build problems described above, there is also a runtime one worth noting. The published latest-development binary does build and start, creates all of its per-domain sockets, and then exits on boot with:
The cause is that a contact object with a new method is defined in both the identity domain and the business domain, so the all-domains build registers contact.new twice. Because domains are selected at compile time, this cannot be avoided at runtime. Building hero_osis without the business domain (all-domains minus business) lets it register once and boot, so de-duplicating contact across the identity and business domains would fix the published binary.
Net: once hero_osis can build from published deps (the request above) and boots without the contact.new collision, wiring it onto the member instances is straightforward on the deployer side. We are parking the hero_osis side as not immediately ours to fix and will pick a split with you from here.
Signed-by: mik-tf mik-tf@noreply.invalid
Downstream impact is now visible end to end. The Hero OS desktop now installs and opens on member instances, and on a live member the Contexts island returns "Socket rpc.sock not found for hero_osis_base, daemon not running" because hero_osis is not installed there (it is not in the member install set, since it cannot build from a clean checkout per this issue). So this build blocker is currently what keeps the desktop's data-backed islands empty on members. Tracking the broader desktop-to-backend wiring (including adding hero_osis to the member install set and running it with the member's contexts once it is buildable) at lhumina_code/home#303.
Signed-by: mik-tf mik-tf@noreply.invalid
Confirming this is still the blocker as of today, with one downstream update.
hero_osis still cannot build from a clean checkout. Cargo.toml lines 48 to 55 still carry the local [patch] pointing at /Users/despiegk and /Volumes/T7, and against the published hero_rpc the OsisObject codegen still throws the roughly 1100 trait and derive errors, so CI and everyone else still fail. Separately the boot crash is also still present: a Contact root object with a .new method is defined in both schemas/identity/contact.oschema and schemas/business/crm.oschema, so the all-domains build panics at startup on a duplicate contact.new registration.
Because hero_osis is not in the member install set, on a live member the desktop shell itself now works (and as of today lands each member in their own named context), but every osis-backed island (Contexts, Finance, and the rest) stays empty with "Socket rpc.sock not found for hero_osis_base, daemon not running".
To unblock, please push your local hero_rpc and hero_lib changes (including herolib_derive) to a shared branch so hero_osis can depend on published versions. Once that is up the local [patch] can be dropped, the small serve_unix update can land, and the duplicate contact.new can be namespaced. Tracking the broader desktop to backend wiring at lhumina_code/home#303.
Signed-by: mik-tf mik-tf@noreply.invalid
hero_osis now builds and boots from a clean checkout. The two cross-domain name collisions were renamed on the business side, and the build pulls its dependencies from git with a known-good library pin, producing a static binary that starts with all domains on the single-socket transport. The work landed on the integration branch. Closing this build blocker. Bringing the pin up to the current library tip is separate follow-up work.