feat(rust): serve GET /info from function-autoscaler and http-invocation

[priyaselvaganesan]

TL;DR

Adds GET /info to the two Rust services, function-autoscaler and http-invocation, completing the endpoint across all three languages. Response schema matches the Go (src/libraries/go/lib/pkg/version, #270) and Java (nv-boot-starter-core, #1212) endpoints:

{"service":"nvcf-function-autoscaler","version":"1.2.3","commit":"16769d1988ff11c19071966db971de23b173f289"}

The schema lives in a new shared crate, src/libraries/rust/nvcf-info, so it is not hand-duplicated per service.

Additional Details

version and commit come from the existing per-service version_env expand_template in crates/server/BUILD.bazel, which already stamped CARGO_PKG_VERSION from STABLE_VERSION for the OTel service.version attribute. This adds NVCF_GIT_COMMIT from STABLE_GIT_COMMIT_FULL, the same workspace-status key the Go services use, so all three languages report the same full SHA. Unstamped local builds fall back to 0.0.0-dev and unknown.

Three things about the shared crate are worth a reviewer's attention.

info_response! is a macro rather than a function. Rust has no equivalent to Go's linker -X stamping of an imported package's variables, so a function here would report nvcf-info's own crate metadata. The macro expands inside the calling crate, where env! reads that crate's stamped values.

The service name is passed to the macro instead of read from CARGO_PKG_NAME. This matches the Go services, which set version.Service to an explicit deployed name in x_defs. It is also necessary: under Bazel, CARGO_PKG_NAME resolves to the rules_rust target name, so deriving it would report rs_autoscaler_lib.

BUILD.bazel builds src/lib.rs once per consuming crate universe. Each Rust service resolves third-party crates from its own crate_universe repo, so @rs_autoscaler_crates//:serde and @nvcf_invocation_crates//:serde are distinct crates and therefore distinct Serialize traits. A single shared target compiles but then fails at the axum::Json bound in one of the two callers.

For the Reviewer

The shared crate is a Bazel dependency only, not a cargo path dependency. cargo-bazel splice copies each service workspace into a temp dir rooted at that workspace, so a path dependency pointing outside the service directory resolves above the splice root and fails to load. I tried the path dependency, a symlink inside the service tree, and giving nvcf-info its own [workspace] table; all three fail the same way.

The consequence is that cargo build/cargo test in function-autoscaler and http-invocation no longer resolve nvcf_info. Bazel is the canonical CI and release path for both, and bazel test covers the same crates, but this does change the local cargo loop documented in those services' AGENTS.md, so both files now say so. If you would rather keep cargo working, the alternative is dropping the shared crate and inlining the 3-field struct in each service. Happy to switch.

MODULE.bazel is unchanged: nvcf-info needs no crate_universe of its own.

Customer Release Notes

function-autoscaler and http-invocation now serve GET /info, returning the service name, release version, and git commit of the running build.

Testing

bazel test --stamp //src/libraries/rust/nvcf-info:all \
  //src/control-plane-services/function-autoscaler/crates/server:all \
  //src/invocation-plane-services/http-invocation/crates/server:all

All three test targets pass. Verified the stamping end to end rather than only through cargo: with --stamp, the generated version.env carries the real STABLE_VERSION and the full STABLE_GIT_COMMIT_FULL, and both stamped server binaries contain that commit string and their own service name.

cargo fmt --check, cargo clippy --all-targets -- -D warnings, and cargo test are clean for nvcf-info itself. cargo fmt --check in http-invocation reports diffs in build.rs, metrics/mod.rs, middleware/spans.rs, and telemetry/settings.rs; those files are untouched here and the diffs come from local rustfmt version skew against the pinned toolchain.

Not exercised against a running cluster. The handlers are pure and covered by unit tests.

Notes

/info is registered on each service's external-facing router next to /health, not on the internal probe port, matching the Go services. On http-invocation it is placed after the auth_middleware layer so it is unauthenticated, same as /health.

Issues

Closes #1578

Related Pull Requests

• feat(go-lib/version): add Handler and HandlerFor http.Handler #270 Go shared handler
• feat(java): add shared GET /info REST controller to nv-boot-starter-core #1212 Java shared controller

Dependencies

None. nvcf-info depends only on serde, already present in both crate universes, plus serde_json as a dev-dependency for the schema test.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

🛡️ CodeQL Analysis

🚨 Found 5 issue(s)

Severity Breakdown:

• 🔴 Errors: 0
• 🟡 Warnings: 0
• 🔵 Notes: 0

📋 Top Issues

🔗 View full details in Security tab

_{🕐 Last updated: 2026-09-04 19:08:40 UTC | Commit: 96dcd5f}