lhumina_code/hero_archipelagos

Fork 0

build: cargo check fails on `messaging` (SDK drift) and `productivity/projects` (enum drift) — regression of #69 #193

New issue

Closed

opened 2026-04-29 13:30:35 +00:00 by rawdaGastan · 2 comments

rawdaGastan commented

2026-04-29 13:30:35 +00:00

Member

Summary

Regression of #69 (closed 2026-04-21). cargo check --workspace against development head (2026-04-29) still fails on the same messaging SDK mismatch, plus a sibling drift in productivity/projects.

The running ~/hero/bin/hero_os_ui (built 2026-04-29 15:07) reflects an older snapshot — anyone touching messaging/projects on development will hit this immediately.

Failures (1 of 2) — `hero_archipelagos_messaging`

error[E0599]: no method named `conversationservice_list_messages` found for struct `CommunicationClient` in the current scope
   --> archipelagos/messaging/src/services/messaging_service.rs:105:10
    |
104 | /     client
105 | |         .conversationservice_list_messages(conversation_sid.to_string())
    | |_________-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
help: there is a method `conversation_list` with a similar name, but with different arguments

Identical surface to the closed #69 — same file, same SDK method, no replacement landed.

Failures (2 of 2) — `hero_archipelagos_projects`

13× E0599 on ProjectStatus::Todo and ProjectStatus::Done not found in the SDK enum:

error[E0599]: no variant or associated item named `Todo` found for enum `hero_osis_sdk::ProjectStatus` in the current scope
   --> archipelagos/productivity/projects/src/views/status_style.rs:7:24
   |
 7 |         ProjectStatus::Todo => "island-status-muted",
   |                        ^^^^ variant or associated item not found

error[E0599]: no variant or associated item named `Done` found for enum `hero_osis_sdk::ProjectStatus`
   --> archipelagos/productivity/projects/src/views/status_style.rs:9:24

Files: archipelagos/productivity/projects/src/views/status_style.rs and …/views/project_form.rs.

Repro

cd hero_archipelagos
make check  # → exit 101

Suggested fix

For messaging: implement the missing SDK method on CommunicationClient (probably conversation.list_messages(sid) returning Vec<ChatMessage>) and update the consumer.

For productivity/projects: realign with the actual ProjectStatus variants in the current hero_osis_sdk (look at hero_osis_sdk/src/projects/types.rs for the canonical names).

#69 (closed) — original messaging SDK drift (same root cause).
#162 (open) — different file (server/src/main.rs), different error class.

Found via QA session 2026-04-29.

## Summary Regression of [#69 (closed 2026-04-21)](https://forge.ourworld.tf/lhumina_code/hero_archipelagos/issues/69). `cargo check --workspace` against `development` head (2026-04-29) still fails on the same `messaging` SDK mismatch, plus a sibling drift in `productivity/projects`. The running `~/hero/bin/hero_os_ui` (built 2026-04-29 15:07) reflects an older snapshot — anyone touching messaging/projects on `development` will hit this immediately. ## Failures (1 of 2) — `hero_archipelagos_messaging` ``` error[E0599]: no method named `conversationservice_list_messages` found for struct `CommunicationClient` in the current scope --> archipelagos/messaging/src/services/messaging_service.rs:105:10 | 104 | / client 105 | | .conversationservice_list_messages(conversation_sid.to_string()) | |_________-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | help: there is a method `conversation_list` with a similar name, but with different arguments ``` Identical surface to the closed #69 — same file, same SDK method, no replacement landed. ## Failures (2 of 2) — `hero_archipelagos_projects` 13× E0599 on `ProjectStatus::Todo` and `ProjectStatus::Done` not found in the SDK enum: ``` error[E0599]: no variant or associated item named `Todo` found for enum `hero_osis_sdk::ProjectStatus` in the current scope --> archipelagos/productivity/projects/src/views/status_style.rs:7:24 | 7 | ProjectStatus::Todo => "island-status-muted", | ^^^^ variant or associated item not found error[E0599]: no variant or associated item named `Done` found for enum `hero_osis_sdk::ProjectStatus` --> archipelagos/productivity/projects/src/views/status_style.rs:9:24 ``` Files: `archipelagos/productivity/projects/src/views/status_style.rs` and `…/views/project_form.rs`. ## Repro ```bash cd hero_archipelagos make check # → exit 101 ``` ## Suggested fix For `messaging`: implement the missing SDK method on `CommunicationClient` (probably `conversation.list_messages(sid)` returning `Vec<ChatMessage>`) and update the consumer. For `productivity/projects`: realign with the actual `ProjectStatus` variants in the current `hero_osis_sdk` (look at `hero_osis_sdk/src/projects/types.rs` for the canonical names). ## Related - [#69 (closed)](https://forge.ourworld.tf/lhumina_code/hero_archipelagos/issues/69) — original `messaging` SDK drift (same root cause). - [#162 (open)](https://forge.ourworld.tf/lhumina_code/hero_archipelagos/issues/162) — different file (`server/src/main.rs`), different error class. Found via QA session 2026-04-29.

rawdaGastan commented

2026-04-29 13:44:05 +00:00

Author

Member

Implementation Spec for Issue #193

Objective

Refresh the pinned hero_osis_sdk git revision in Cargo.lock so the workspace compiles against the SDK head that already contains conversationservice_list_messages and the shrunken ProjectStatus { Todo, InProgress, Done }. No consumer source changes are needed — this is a lock-file regression, not a code regression.

Requirements

cargo check --workspace (and therefore make check) exits 0 on the development head.
The fix updates only the SDK pin in Cargo.lock; no .rs source files need to change because they already use the new API surface.
No SDK-side changes (this issue is filed against hero_archipelagos; the SDK already has the methods and enum variants on its development head).
The fix must be reproducible in CI — not rely on a specific developer's local hero_osis checkout.

Files to Modify/Create

Cargo.lock — bump the hero_osis_sdk git source SHA from the stale 7acc28c53e61b1439d773587dcaa9b2d8641c53e (Apr 15) to current head 1aee7b8 on lhumina_code/hero_osis@development, which contains commits e0e02dd (list_messages RPC, Apr 19) and 69c998a (ProjectStatus shrink, Apr 20). Done via cargo update -p hero_osis_sdk.

Implementation Plan

Step 1: Verify the diagnosis

Files: read-only

Confirm Cargo.toml pins hero_osis_sdk = { git = "...hero_osis.git", branch = "development" } (branch-tracked, no rev pin).
Confirm Cargo.lock records source = "git+...?branch=development#7acc28c53e61b1439d773587dcaa9b2d8641c53e" for hero_osis_sdk. This SHA predates both fix commits.
Confirm SDK head at crates/hero_osis_sdk/src/communication/osis_client_generated.rs:805 exposes conversationservice_list_messages(conversation_sid: String) -> Result<Vec<ChatMessage>, _> — exact signature the consumer calls.
Confirm SDK head at crates/hero_osis_sdk/src/projects/types.rs declares enum ProjectStatus { Todo, InProgress, Done } — exact variants the consumer uses.
Dependencies: none.

Step 2: Refresh the SDK lock entry

Files: Cargo.lock

From the hero_archipelagos repo root run: cargo update -p hero_osis_sdk.
This re-resolves the branch = "development" git dependency to the current head SHA, rewrites the hero_osis_sdk entry in Cargo.lock, and triggers a fresh git fetch into ~/.cargo/git/.
Do NOT manually edit Cargo.lock SHAs; let cargo do it.
Do NOT touch Cargo.toml — the branch = "development" pin is correct.
Dependencies: Step 1.

Step 3: Verify the workspace compiles

Files: none (read-only verification)

Run make check (= cargo check). Expect exit 0; no E0599 errors on ProjectStatus::Todo/Done or conversationservice_list_messages.
Run cargo check --workspace explicitly so non-default-feature crates also build.
Spot-check cargo tree -p hero_osis_sdk reports the new SHA.
Dependencies: Step 2.

Acceptance Criteria

cd hero_archipelagos && make check exits 0.
cd hero_archipelagos && cargo check --workspace exits 0.
Cargo.lock shows hero_osis_sdk pinned to a SHA that descends from both e0e02dd (list_messages) and 69c998a (ProjectStatus shrink).
No .rs source files under archipelagos/messaging/ or archipelagos/productivity/projects/ are modified by this PR — the diff is Cargo.lock-only.
No new clippy warnings introduced relative to pre-fix baseline.

Notes

The issue body's "two strategies" framing for messaging (rename method vs. fall back to chatmessage_list + filter) is moot: the SDK head already exposes the exact method name + signature the consumer uses. The "no method found" error is purely a lock-file drift artifact, not a source bug.
Issue body undercounted projects-island call sites. Variants Todo/InProgress/Done are also referenced in archipelagos/productivity/projects/src/views/board_view.rs (lines 33–35, 96, 104, 112) and archipelagos/productivity/projects/src/services/project_service.rs:154. All compile fine after the lock refresh — they already use the correct post-shrink names.
The locked SHA 7acc28c (Apr 15) predates e0e02dd (Apr 19) and 69c998a (Apr 20). Anyone who ran cargo update after Apr 20 would not see the regression; anyone doing a fresh checkout-and-build with the existing lock would. CI evidently uses the existing lock, hence the regression.
The local checkout at /home/rawda/projects/hero_os_repos/hero_osis does NOT influence the build because Cargo.toml uses git = "..." not path = "...". The build pulls from the remote into ~/.cargo/git/. The fix must be a lock refresh, not a local-tree edit.
Do NOT add [patch] or source-replacement entries pointing at the local hero_osis checkout — that would couple this repo to one developer's filesystem layout.

Follow-up suggestions (out of scope here, do not implement now)

This is the second occurrence of the same drift (regression of #69). Root cause is structural: Cargo.lock is committed but never refreshed in CI for git-tracked deps with branch pins, so the lock can lag the SDK branch indefinitely until somebody runs cargo update locally.

Add a CI step that runs cargo update -p hero_osis_sdk (and any other Hero-sourced crates) on each PR build, fails if the lock changes, prompting the author to commit the refresh — or commits it automatically.
Or pin hero_osis_sdk to a specific rev = "..." instead of branch = "development" and bump intentionally — drift becomes visible at PR review.

These should be filed as separate tickets after this PR lands.

## Implementation Spec for Issue #193 ### Objective Refresh the pinned `hero_osis_sdk` git revision in `Cargo.lock` so the workspace compiles against the SDK head that already contains `conversationservice_list_messages` and the shrunken `ProjectStatus { Todo, InProgress, Done }`. No consumer source changes are needed — this is a lock-file regression, not a code regression. ### Requirements - `cargo check --workspace` (and therefore `make check`) exits 0 on the `development` head. - The fix updates only the SDK pin in `Cargo.lock`; no `.rs` source files need to change because they already use the new API surface. - No SDK-side changes (this issue is filed against `hero_archipelagos`; the SDK already has the methods and enum variants on its `development` head). - The fix must be reproducible in CI — not rely on a specific developer's local `hero_osis` checkout. ### Files to Modify/Create - `Cargo.lock` — bump the `hero_osis_sdk` git source SHA from the stale `7acc28c53e61b1439d773587dcaa9b2d8641c53e` (Apr 15) to current head `1aee7b8` on `lhumina_code/hero_osis@development`, which contains commits `e0e02dd` (`list_messages` RPC, Apr 19) and `69c998a` (ProjectStatus shrink, Apr 20). Done via `cargo update -p hero_osis_sdk`. ### Implementation Plan #### Step 1: Verify the diagnosis Files: read-only - Confirm `Cargo.toml` pins `hero_osis_sdk = { git = "...hero_osis.git", branch = "development" }` (branch-tracked, no rev pin). - Confirm `Cargo.lock` records `source = "git+...?branch=development#7acc28c53e61b1439d773587dcaa9b2d8641c53e"` for `hero_osis_sdk`. This SHA predates both fix commits. - Confirm SDK head at `crates/hero_osis_sdk/src/communication/osis_client_generated.rs:805` exposes `conversationservice_list_messages(conversation_sid: String) -> Result<Vec<ChatMessage>, _>` — exact signature the consumer calls. - Confirm SDK head at `crates/hero_osis_sdk/src/projects/types.rs` declares `enum ProjectStatus { Todo, InProgress, Done }` — exact variants the consumer uses. Dependencies: none. #### Step 2: Refresh the SDK lock entry Files: `Cargo.lock` - From the `hero_archipelagos` repo root run: `cargo update -p hero_osis_sdk`. - This re-resolves the `branch = "development"` git dependency to the current head SHA, rewrites the `hero_osis_sdk` entry in `Cargo.lock`, and triggers a fresh `git fetch` into `~/.cargo/git/`. - Do NOT manually edit `Cargo.lock` SHAs; let cargo do it. - Do NOT touch `Cargo.toml` — the `branch = "development"` pin is correct. Dependencies: Step 1. #### Step 3: Verify the workspace compiles Files: none (read-only verification) - Run `make check` (= `cargo check`). Expect exit 0; no `E0599` errors on `ProjectStatus::Todo`/`Done` or `conversationservice_list_messages`. - Run `cargo check --workspace` explicitly so non-default-feature crates also build. - Spot-check `cargo tree -p hero_osis_sdk` reports the new SHA. Dependencies: Step 2. ### Acceptance Criteria - [ ] `cd hero_archipelagos && make check` exits 0. - [ ] `cd hero_archipelagos && cargo check --workspace` exits 0. - [ ] `Cargo.lock` shows `hero_osis_sdk` pinned to a SHA that descends from both `e0e02dd` (list_messages) and `69c998a` (ProjectStatus shrink). - [ ] No `.rs` source files under `archipelagos/messaging/` or `archipelagos/productivity/projects/` are modified by this PR — the diff is `Cargo.lock`-only. - [ ] No new clippy warnings introduced relative to pre-fix baseline. ### Notes - The issue body's "two strategies" framing for messaging (rename method vs. fall back to `chatmessage_list` + filter) is moot: the SDK head already exposes the exact method name + signature the consumer uses. The "no method found" error is purely a lock-file drift artifact, not a source bug. - Issue body undercounted projects-island call sites. Variants `Todo`/`InProgress`/`Done` are also referenced in `archipelagos/productivity/projects/src/views/board_view.rs` (lines 33–35, 96, 104, 112) and `archipelagos/productivity/projects/src/services/project_service.rs:154`. All compile fine after the lock refresh — they already use the correct post-shrink names. - The locked SHA `7acc28c` (Apr 15) predates `e0e02dd` (Apr 19) and `69c998a` (Apr 20). Anyone who ran `cargo update` after Apr 20 would not see the regression; anyone doing a fresh checkout-and-build with the existing lock would. CI evidently uses the existing lock, hence the regression. - The local checkout at `/home/rawda/projects/hero_os_repos/hero_osis` does NOT influence the build because `Cargo.toml` uses `git = "..."` not `path = "..."`. The build pulls from the remote into `~/.cargo/git/`. The fix must be a lock refresh, not a local-tree edit. - Do NOT add `[patch]` or source-replacement entries pointing at the local `hero_osis` checkout — that would couple this repo to one developer's filesystem layout. ### Follow-up suggestions (out of scope here, do not implement now) This is the second occurrence of the same drift (regression of #69). Root cause is structural: `Cargo.lock` is committed but never refreshed in CI for git-tracked deps with branch pins, so the lock can lag the SDK branch indefinitely until somebody runs `cargo update` locally. 1. Add a CI step that runs `cargo update -p hero_osis_sdk` (and any other Hero-sourced crates) on each PR build, fails if the lock changes, prompting the author to commit the refresh — or commits it automatically. 2. Or pin `hero_osis_sdk` to a specific `rev = "..."` instead of `branch = "development"` and bump intentionally — drift becomes visible at PR review. These should be filed as separate tickets after this PR lands.

rawdaGastan commented

2026-04-29 14:21:37 +00:00

Author

Member

Closing — CI is not actually broken

After investigation, this is not a CI/release-blocking issue and there is no committable fix that would close it as filed. Closing with the workaround documented for anyone who hits the symptom locally.

Diagnosis

Cargo.lock is in .gitignore (line 4) for this repo. CI on development therefore starts every build with no lock and resolves hero_osis_sdk = { git = "...", branch = "development" } to the SDK head SHA at the moment of the run. Recent CI runs on development (PRs #179, #180, #181) all completed successfully against the current SDK.

The symptom — cargo check failing on conversationservice_list_messages not found and ProjectStatus::Todo/Done not found — only appears on developer working trees that have a stale local Cargo.lock from a build done before the SDK drift commits landed. The .gitignore keeps the local lock alive across SDK changes, but nothing forces a refresh.

Workaround for affected developers

cd hero_archipelagos
cargo update -p hero_osis_sdk
make check  # exits 0

Verified locally on 2026-04-29: refresh moved the lock from SDK SHA 7acc28c5 (Apr 15) to 1aee7b83 (current development head) and cargo check passes.

Why no PR

A cargo update -p hero_osis_sdk produces a modified Cargo.lock only — and Cargo.lock is .gitignored, so git status is clean afterward. There is nothing to commit. Pinning to a specific rev = "..." in Cargo.toml, or removing Cargo.lock from .gitignore, are both structural changes outside the scope of "fix the build" and worth deciding deliberately as separate tickets if the maintainers want to prevent recurrence.

Suggested follow-up tickets (not filing now — leaving to maintainer judgement)

Make make check self-healing — prepend cargo update -p hero_osis_sdk (and any other Hero-sourced crate) to the check target in Makefile so a stale local lock auto-refreshes on first attempt. One-line change, fixes the developer-experience trap without changing dep-resolution conventions.
Reconsider the Cargo.lock gitignore policy — this workspace builds binaries (WASM islands + a server). Conventional Rust guidance is to commit Cargo.lock for binaries/applications. Doing so would give every developer + CI the same SDK pin and surface drift at PR review.
Pin SDK to a specific rev — most explicit, makes drift visible at PR review, but requires intentional bumps for every SDK change.

Closing.

## Closing — CI is not actually broken After investigation, this is not a CI/release-blocking issue and there is no committable fix that would close it as filed. Closing with the workaround documented for anyone who hits the symptom locally. ### Diagnosis `Cargo.lock` is in `.gitignore` (line 4) for this repo. CI on `development` therefore starts every build with no lock and resolves `hero_osis_sdk = { git = "...", branch = "development" }` to the SDK head SHA at the moment of the run. Recent CI runs on `development` (PRs #179, #180, #181) all completed successfully against the current SDK. The symptom — `cargo check` failing on `conversationservice_list_messages` not found and `ProjectStatus::Todo`/`Done` not found — only appears on **developer working trees** that have a stale local `Cargo.lock` from a build done before the SDK drift commits landed. The `.gitignore` keeps the local lock alive across SDK changes, but nothing forces a refresh. ### Workaround for affected developers ```bash cd hero_archipelagos cargo update -p hero_osis_sdk make check # exits 0 ``` Verified locally on 2026-04-29: refresh moved the lock from SDK SHA `7acc28c5` (Apr 15) to `1aee7b83` (current `development` head) and `cargo check` passes. ### Why no PR A `cargo update -p hero_osis_sdk` produces a modified `Cargo.lock` only — and `Cargo.lock` is `.gitignore`d, so `git status` is clean afterward. There is nothing to commit. Pinning to a specific `rev = "..."` in `Cargo.toml`, or removing `Cargo.lock` from `.gitignore`, are both structural changes outside the scope of "fix the build" and worth deciding deliberately as separate tickets if the maintainers want to prevent recurrence. ### Suggested follow-up tickets (not filing now — leaving to maintainer judgement) 1. **Make `make check` self-healing** — prepend `cargo update -p hero_osis_sdk` (and any other Hero-sourced crate) to the `check` target in `Makefile` so a stale local lock auto-refreshes on first attempt. One-line change, fixes the developer-experience trap without changing dep-resolution conventions. 2. **Reconsider the `Cargo.lock` gitignore policy** — this workspace builds binaries (WASM islands + a server). Conventional Rust guidance is to commit `Cargo.lock` for binaries/applications. Doing so would give every developer + CI the same SDK pin and surface drift at PR review. 3. **Pin SDK to a specific `rev`** — most explicit, makes drift visible at PR review, but requires intentional bumps for every SDK change. Closing.