CI red on development: stale Cargo.lock pin of hero_proc_sdk #34

New issue

Closed

opened 2026-04-27 11:01:20 +00:00 by fatmaebrahim · 4 comments

fatmaebrahim commented 2026-04-27 11:01:20 +00:00

Member

Copy link

Every PR against development fails make check with error[E0560]: struct JobCreateInput has no field named inputs at crates/service/src/lifecycle.rs:290.

Cargo.lock pins hero_proc_sdk to hero_proc commit 8e7e985 (2026-04-08), which is older than c84abac (2026-04-15) where the inputs field was added.

The call site already passes inputs: None, so the source is correct — only the lock is stale.

Every PR against `development` fails `make check` with `error[E0560]: struct JobCreateInput has no field named inputs` at `crates/service/src/lifecycle.rs:290`. `Cargo.lock` pins `hero_proc_sdk` to hero_proc commit `8e7e985` (2026-04-08), which is older than `c84abac` (2026-04-15) where the `inputs` field was added. The call site already passes `inputs: None`, so the source is correct — only the lock is stale.

fatmaebrahim self-assigned this 2026-04-27 11:02:34 +00:00

fatmaebrahim commented 2026-04-27 11:09:15 +00:00

Author

Member

Copy link

Spec — Refresh stale hero_proc_sdk pin in Cargo.lock (issue #34)

Objective

Unblock CI on development by refreshing the hero_proc_sdk entry in Cargo.lock so it resolves to the current development HEAD of hero_proc (which contains the JobCreateInput.inputs field). The Rust source already passes inputs: None at the only call site, so no source code change is required — only the lock file is stale.

Requirements

• make check must succeed on development and on PRs targeting development, both locally and in the Forgejo Test workflow.
• The fix must not change the public API of any crate in this workspace.
• The fix must not bump unrelated dependencies (use a targeted cargo update -p, not a full cargo update).
• The manifest declarations of hero_proc_sdk must remain branch-tracking on development (no rev = should be introduced).
• The Cargo.lock entry for hero_proc_sdk must end up at the latest development HEAD of hero_proc at the time of the fix — do not hand-pick or hardcode any specific commit SHA.

Files to Modify/Create

File	Change	Why
Cargo.lock	Regenerated entry for hero_proc_sdk: the source = "git+...?branch=development#<sha>" line will move to the current development HEAD of hero_proc. Transitive checksum lines may also update.	Restores compilation: stale pin lacks the inputs field on JobCreateInput.

No other files are modified or created. Specifically, do not touch:

• crates/service/Cargo.toml (already declares the git+branch dep correctly)
• crates/server/Cargo.toml (already declares the git+branch dep correctly)
• crates/service/src/lifecycle.rs (line 290 already uses inputs: None)

Implementation Plan

All commands assume cwd is the repo root and a working Rust toolchain.

1. Confirm the workspace state is clean before touching the lock.

   git status
   git rev-parse --abbrev-ref HEAD
   

   You should be on a feature branch off development with no unrelated edits staged. If Cargo.lock is already dirty, stop and inspect.

2. Re-resolve only hero_proc_sdk against the current development HEAD. Because both crates/service/Cargo.toml and crates/server/Cargo.toml declare the dep as { git = "...hero_proc.git", branch = "development", version = "0.5.0" } with no rev =, a targeted update is sufficient — no manifest edit is required and no SHA needs to be specified by hand.

   cargo update -p hero_proc_sdk
   

   Cargo will fetch the current development tip from the remote and rewrite the lock to point at it. Expected output line:

   Updating hero_proc_sdk v0.5.0 (https://forge.ourworld.tf/lhumina_code/hero_proc.git?branch=development#<old-sha>) -> #<new-sha>
   

3. Verify the lock now points at the new commit.

   grep -n -A1 '^name = "hero_proc_sdk"' Cargo.lock
   

   The source = "git+https://forge.ourworld.tf/lhumina_code/hero_proc.git?branch=development#<sha>" line must show a SHA different from the previous one and must match the current development HEAD of hero_proc (cross-check with git ls-remote https://forge.ourworld.tf/lhumina_code/hero_proc.git refs/heads/development).

4. Reproduce CI's check locally.

   make check
   

   This runs cargo check --workspace --exclude recipe_server. It must complete with no E0560 error at crates/service/src/lifecycle.rs:290.

5. Sanity-check the broader build (recommended given the SDK touches both hero_service and hero_server).

   make build
   make test
   

6. Commit only the lock file.

   git diff --stat                 # should show only Cargo.lock
   git add Cargo.lock
   git commit -m "chore(deps): refresh hero_proc_sdk pin in Cargo.lock for JobCreateInput.inputs"
   

7. Push and let the Forgejo Test workflow (.forgejo/workflows/test.yaml) run make check / make test to confirm CI is green.

Step dependencies

• 2 depends on 1.
• 3, 4, 5 depend on 2.
• 6 depends on 4 (must pass before commit).
• 7 depends on 6.

Acceptance Criteria

• Cargo.lock [[package]] name = "hero_proc_sdk" entry's source = "git+...?branch=development#<sha>" SHA matches the current development HEAD of hero_proc (verified via git ls-remote).
• The new SHA contains the inputs field on JobCreateInput (implied by matching development HEAD).
• make check exits 0 locally with no error[E0560] and no other new errors.
• make test exits 0 locally.
• No files changed other than Cargo.lock.
• crates/service/Cargo.toml and crates/server/Cargo.toml still declare hero_proc_sdk as { git = "https://forge.ourworld.tf/lhumina_code/hero_proc.git", branch = "development", version = "0.5.0" } with no rev key.
• The Forgejo Test workflow (Check step) passes on the PR against development.

Notes

• The manifest does NOT need to change. Both crates/service/Cargo.toml and crates/server/Cargo.toml already use branch = "development" without a fixed rev =, so Cargo picks up whatever development HEAD is at resolve time. The lock got stale because nobody has re-resolved it since the inputs field was added.
• No SHA is hardcoded into the fix. cargo update -p hero_proc_sdk always pulls the latest development tip — that is the desired behavior. Do not edit the lock by hand or pin a specific commit.
• Both hero_rpc_server and hero_service transitively depend on hero_proc_sdk, so refreshing the single hero_proc_sdk entry is sufficient — Cargo will reuse the new resolved commit for both.
• Use cargo update -p hero_proc_sdk (targeted), not a bare cargo update, to avoid churning unrelated transitive deps.
• The Forgejo Test workflow already clears $CARGO_HOME/git/db/hero_rpc-* and hero_lib-* caches but not hero_proc-*. That doesn't matter for this fix — the lock file is what determines the resolved commit, and CI uses the committed lock as-is.
• The call site at crates/service/src/lifecycle.rs:287-291 is already correct:

  client.job_create(hero_proc_sdk::JobCreateInput {
      spec,
      context: Some(self.context.clone()),
      inputs: None,
  })
  

  Do not modify it.

# Spec — Refresh stale `hero_proc_sdk` pin in `Cargo.lock` (issue #34) ## Objective Unblock CI on `development` by refreshing the `hero_proc_sdk` entry in `Cargo.lock` so it resolves to the current `development` HEAD of `hero_proc` (which contains the `JobCreateInput.inputs` field). The Rust source already passes `inputs: None` at the only call site, so no source code change is required — only the lock file is stale. ## Requirements - `make check` must succeed on `development` and on PRs targeting `development`, both locally and in the Forgejo `Test` workflow. - The fix must not change the public API of any crate in this workspace. - The fix must not bump unrelated dependencies (use a targeted `cargo update -p`, not a full `cargo update`). - The manifest declarations of `hero_proc_sdk` must remain branch-tracking on `development` (no `rev =` should be introduced). - The `Cargo.lock` entry for `hero_proc_sdk` must end up at the latest `development` HEAD of `hero_proc` at the time of the fix — do not hand-pick or hardcode any specific commit SHA. ## Files to Modify/Create | File | Change | Why | |---|---|---| | `Cargo.lock` | Regenerated entry for `hero_proc_sdk`: the `source = "git+...?branch=development#<sha>"` line will move to the current `development` HEAD of `hero_proc`. Transitive checksum lines may also update. | Restores compilation: stale pin lacks the `inputs` field on `JobCreateInput`. | No other files are modified or created. Specifically, **do not** touch: - `crates/service/Cargo.toml` (already declares the git+branch dep correctly) - `crates/server/Cargo.toml` (already declares the git+branch dep correctly) - `crates/service/src/lifecycle.rs` (line 290 already uses `inputs: None`) ## Implementation Plan All commands assume cwd is the repo root and a working Rust toolchain. 1. **Confirm the workspace state is clean before touching the lock.** ``` git status git rev-parse --abbrev-ref HEAD ``` You should be on a feature branch off `development` with no unrelated edits staged. If `Cargo.lock` is already dirty, stop and inspect. 2. **Re-resolve only `hero_proc_sdk` against the current `development` HEAD.** Because both `crates/service/Cargo.toml` and `crates/server/Cargo.toml` declare the dep as `{ git = "...hero_proc.git", branch = "development", version = "0.5.0" }` with **no `rev =`**, a targeted update is sufficient — no manifest edit is required and no SHA needs to be specified by hand. ``` cargo update -p hero_proc_sdk ``` Cargo will fetch the current `development` tip from the remote and rewrite the lock to point at it. Expected output line: ``` Updating hero_proc_sdk v0.5.0 (https://forge.ourworld.tf/lhumina_code/hero_proc.git?branch=development#<old-sha>) -> #<new-sha> ``` 3. **Verify the lock now points at the new commit.** ``` grep -n -A1 '^name = "hero_proc_sdk"' Cargo.lock ``` The `source = "git+https://forge.ourworld.tf/lhumina_code/hero_proc.git?branch=development#<sha>"` line must show a SHA different from the previous one and must match the current `development` HEAD of `hero_proc` (cross-check with `git ls-remote https://forge.ourworld.tf/lhumina_code/hero_proc.git refs/heads/development`). 4. **Reproduce CI's check locally.** ``` make check ``` This runs `cargo check --workspace --exclude recipe_server`. It must complete with no `E0560` error at `crates/service/src/lifecycle.rs:290`. 5. **Sanity-check the broader build (recommended given the SDK touches both `hero_service` and `hero_server`).** ``` make build make test ``` 6. **Commit only the lock file.** ``` git diff --stat # should show only Cargo.lock git add Cargo.lock git commit -m "chore(deps): refresh hero_proc_sdk pin in Cargo.lock for JobCreateInput.inputs" ``` 7. **Push and let the Forgejo `Test` workflow (`.forgejo/workflows/test.yaml`) run `make check` / `make test` to confirm CI is green.** ### Step dependencies - 2 depends on 1. - 3, 4, 5 depend on 2. - 6 depends on 4 (must pass before commit). - 7 depends on 6. ## Acceptance Criteria - [ ] `Cargo.lock` `[[package]] name = "hero_proc_sdk"` entry's `source = "git+...?branch=development#<sha>"` SHA matches the current `development` HEAD of `hero_proc` (verified via `git ls-remote`). - [ ] The new SHA contains the `inputs` field on `JobCreateInput` (implied by matching `development` HEAD). - [ ] `make check` exits 0 locally with no `error[E0560]` and no other new errors. - [ ] `make test` exits 0 locally. - [ ] No files changed other than `Cargo.lock`. - [ ] `crates/service/Cargo.toml` and `crates/server/Cargo.toml` still declare `hero_proc_sdk` as `{ git = "https://forge.ourworld.tf/lhumina_code/hero_proc.git", branch = "development", version = "0.5.0" }` with no `rev` key. - [ ] The Forgejo `Test` workflow (`Check` step) passes on the PR against `development`. ## Notes - **The manifest does NOT need to change.** Both `crates/service/Cargo.toml` and `crates/server/Cargo.toml` already use `branch = "development"` without a fixed `rev =`, so Cargo picks up whatever `development` HEAD is at resolve time. The lock got stale because nobody has re-resolved it since the `inputs` field was added. - **No SHA is hardcoded into the fix.** `cargo update -p hero_proc_sdk` always pulls the latest `development` tip — that is the desired behavior. Do not edit the lock by hand or pin a specific commit. - Both `hero_rpc_server` and `hero_service` transitively depend on `hero_proc_sdk`, so refreshing the single `hero_proc_sdk` entry is sufficient — Cargo will reuse the new resolved commit for both. - Use `cargo update -p hero_proc_sdk` (targeted), not a bare `cargo update`, to avoid churning unrelated transitive deps. - The Forgejo `Test` workflow already clears `$CARGO_HOME/git/db/hero_rpc-*` and `hero_lib-*` caches but **not** `hero_proc-*`. That doesn't matter for this fix — the lock file is what determines the resolved commit, and CI uses the committed lock as-is. - The call site at `crates/service/src/lifecycle.rs:287-291` is already correct: ```rust client.job_create(hero_proc_sdk::JobCreateInput { spec, context: Some(self.context.clone()), inputs: None, }) ``` Do not modify it.

fatmaebrahim commented 2026-04-27 11:18:00 +00:00

Author

Member

Copy link

Test Results

make check and make test were run locally on branch development_refresh_hero_proc_sdk_lock (rustc 1.94.1, cargo 1.94.1).

make check

Passed. The error[E0560]: struct JobCreateInput has no field named inputs reported in this issue is gone.

make test

Passed. 274 tests passed, 0 failed, 1 ignored across all workspace crates.

Crate / target	Result
derive	0 passed
client	1 passed
openrpc	105 passed, 1 ignored
oschema	0 passed
generator	12 passed
osis	62 passed
rpc_server	73 passed
rpc_server (integration)	13 passed
service	8 passed
service / petstore_* (bins)	0 passed

Notes

• cargo update -p hero_proc_sdk re-resolved the lock to current hero_proc development HEAD (9b134018). It also pulled hero_rpc_derive and hero_rpc_openrpc to current hero_rpc development HEAD (38a09290) since they are git deps reachable through hero_proc_sdk — both are branch-tracking, so this is the desired refresh, not an unintended bump.
• After the lock refresh, make test surfaced a pre-existing test-only compile error at crates/osis/src/rpc/request_context.rs:296 (the RequestContext literal in test_serde_roundtrip was missing the hero_context_name: Option<String> field added in commit 7d14133). This was previously masked behind the make check failure that this issue is about. A one-line fix (hero_context_name: None,) is included in this PR so the Test step also passes — the alternative would be a partially green CI on every future PR until that test was patched.

## Test Results `make check` and `make test` were run locally on branch `development_refresh_hero_proc_sdk_lock` (rustc 1.94.1, cargo 1.94.1). ### `make check` Passed. The `error[E0560]: struct JobCreateInput has no field named inputs` reported in this issue is gone. ### `make test` Passed. 274 tests passed, 0 failed, 1 ignored across all workspace crates. | Crate / target | Result | |---|---| | derive | 0 passed | | client | 1 passed | | openrpc | 105 passed, 1 ignored | | oschema | 0 passed | | generator | 12 passed | | osis | 62 passed | | rpc_server | 73 passed | | rpc_server (integration) | 13 passed | | service | 8 passed | | service / petstore_* (bins) | 0 passed | ### Notes - `cargo update -p hero_proc_sdk` re-resolved the lock to current `hero_proc` `development` HEAD (`9b134018`). It also pulled `hero_rpc_derive` and `hero_rpc_openrpc` to current `hero_rpc` `development` HEAD (`38a09290`) since they are git deps reachable through `hero_proc_sdk` — both are branch-tracking, so this is the desired refresh, not an unintended bump. - After the lock refresh, `make test` surfaced a pre-existing test-only compile error at `crates/osis/src/rpc/request_context.rs:296` (the `RequestContext` literal in `test_serde_roundtrip` was missing the `hero_context_name: Option<String>` field added in commit `7d14133`). This was previously masked behind the `make check` failure that this issue is about. A one-line fix (`hero_context_name: None,`) is included in this PR so the Test step also passes — the alternative would be a partially green CI on every future PR until that test was patched.

fatmaebrahim commented 2026-04-27 11:18:46 +00:00

Author

Member

Copy link

Implementation Summary

Changes

File	Change
Cargo.lock	Refreshed hero_proc_sdk from 8e7e9850 to current hero_proc development HEAD 9b134018 (which contains the JobCreateInput.inputs field). Cargo also re-resolved hero_rpc_derive and hero_rpc_openrpc to the current hero_rpc development HEAD 38a09290, since both are git deps reachable through hero_proc_sdk. No manifest changes — both deps remain branch = "development" with no fixed rev.
crates/osis/src/rpc/request_context.rs	Added one missing field (hero_context_name: None) to the RequestContext literal in test_serde_roundtrip. The struct field was added in commit 7d14133 but the test was never updated; the test compile error was previously masked behind the make check failure that this issue is about.

Verification

• make check passes — the original error[E0560]: struct JobCreateInput has no field named inputs at crates/service/src/lifecycle.rs:290 is gone.
• make test passes — 274 tests passed, 0 failed, 1 ignored across all workspace crates.

Notes

• No source-level call site changes were needed for the original lock issue: crates/service/src/lifecycle.rs:290 already passes inputs: None.
• The fix uses cargo update -p hero_proc_sdk (targeted) — no hand-edited SHAs, no broad cargo update, no rev = introduced into manifests. Future stale-lock incidents on this dep can be resolved the same way.

## Implementation Summary ### Changes | File | Change | |---|---| | `Cargo.lock` | Refreshed `hero_proc_sdk` from `8e7e9850` to current `hero_proc` `development` HEAD `9b134018` (which contains the `JobCreateInput.inputs` field). Cargo also re-resolved `hero_rpc_derive` and `hero_rpc_openrpc` to the current `hero_rpc` `development` HEAD `38a09290`, since both are git deps reachable through `hero_proc_sdk`. No manifest changes — both deps remain `branch = "development"` with no fixed `rev`. | | `crates/osis/src/rpc/request_context.rs` | Added one missing field (`hero_context_name: None`) to the `RequestContext` literal in `test_serde_roundtrip`. The struct field was added in commit `7d14133` but the test was never updated; the test compile error was previously masked behind the `make check` failure that this issue is about. | ### Verification - `make check` passes — the original `error[E0560]: struct JobCreateInput has no field named inputs` at `crates/service/src/lifecycle.rs:290` is gone. - `make test` passes — 274 tests passed, 0 failed, 1 ignored across all workspace crates. ### Notes - No source-level call site changes were needed for the original lock issue: `crates/service/src/lifecycle.rs:290` already passes `inputs: None`. - The fix uses `cargo update -p hero_proc_sdk` (targeted) — no hand-edited SHAs, no broad `cargo update`, no `rev =` introduced into manifests. Future stale-lock incidents on this dep can be resolved the same way.

fatmaebrahim referenced this issue from a commit 2026-04-27 11:19:37 +00:00

chore(deps): refresh hero_proc_sdk pin in Cargo.lock for JobCreateInput.inputs

fatmaebrahim referenced this issue 2026-04-27 11:20:14 +00:00

Refresh hero_proc_sdk pin in Cargo.lock for JobCreateInput.inputs #35

fatmaebrahim commented 2026-04-27 11:20:22 +00:00

Author

Member

Copy link

Pull request opened: #35

This PR implements the changes discussed in this issue.

Pull request opened: https://forge.ourworld.tf/lhumina_code/hero_rpc/pulls/35 This PR implements the changes discussed in this issue.

fatmaebrahim referenced this issue from a pull request that will close it, 2026-04-27 11:39:51 +00:00

Refresh hero_proc_sdk pin in Cargo.lock for JobCreateInput.inputs #35

mik-tf closed this issue 2026-04-27 12:53:52 +00:00

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

development

development_fix_delete_deserialize_type

refactor/adr-001-crate-topology

fix/dev-build-proc-sdk-bump

defat_osis_rpc

development_context_names

development_per_domain

development_mik01

feat/parametrized-socket-path-optionality

development_rethinking

main

v0.1.0

Labels

Clear labels   

prio_critical

  

prio_low

  

type_bug

  

type_contact

  

type_issue

  

type_lead

  

type_question

  

type_story

  

type_task

No labels

prio_critical

prio_low

type_bug

type_contact

type_issue

type_lead

type_question

type_story

type_task

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

fatmaebrahim

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

lhumina_code/hero_rpc#34

No description provided.