Stamp stdiod client_version from the desktop release version - #58
Merged
Conversation
The daemon reported its version via env!("CARGO_PKG_VERSION"), but the Rust
workspace version is pinned at 0.0.1 and never bumped per release. Every shipped
daemon therefore announced client_version "0.0.1" in the tunnel handshake and
device-authorization request, so the dashboard Devices page showed 0.0.1 for
every device regardless of the actual release (desktop app is at 0.6.4).
Add a build.rs that stamps the version from the desktop app's
packages/desktop/package.json (the single source of truth for the shipped
release), overridable via SEALGATE_DAEMON_VERSION for CI and falling back to
the crate version. Expose it as config::DAEMON_VERSION and use it for the
handshake, the device-code request, and the CLI --version output.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UfUAccF8W5Prwp4BCWx7np
Address thermo-nuclear review of the version-stamping change:
- Wire up the SEALGATE_DAEMON_VERSION override that build.rs documents as the
primary, robust path but which was previously set by nobody. The desktop
build scripts (build-stdiod{,-win,-linux}.sh) now export it from
packages/desktop/package.json before invoking cargo, so shipped-release
correctness no longer depends on build.rs locating the file by walking the
tree. CLIENT_DIR/package.json is authoritative in both the monorepo and the
sibling-checkout layout.
- Replace the hand-rolled JSON scan in read_json_version with serde_json (added
as a build-dependency; already a normal dependency). The old scan returned the
first "version" substring anywhere in the file, so a nested version key (a tool
pin, a dependency block) could be reported as the daemon version.
- Make the crate-version fallback loud: emit cargo:warning when neither the
override nor a package.json is found, rather than silently shipping the pinned
0.0.1 this change exists to avoid.
The in-tree package.json walk is kept as a zero-ceremony fallback so a plain
cargo build/test still reports the real version.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UfUAccF8W5Prwp4BCWx7np
|
ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing |
Adding the DAEMON_VERSION const and its doc comment to config.rs pushed it to 802 lines, over the stdiod large-file check's 800-line error threshold. Move the const to the crate root (main.rs), where clap's `version =` already consumes it, and reference it as crate::DAEMON_VERSION from daemon.rs and auth.rs. config.rs returns to 792 lines; no new file is added, so the folder-size check is unaffected. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UfUAccF8W5Prwp4BCWx7np
There was a problem hiding this comment.
All reported issues were addressed
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
Fix issues from the cubic review of the version stamping: - Build scripts respect a pre-set SEALGATE_DAEMON_VERSION instead of always overwriting it from package.json, so the override build.rs documents as precedence #1 actually takes effect (all three scripts). - Bound the ancestor walk in build.rs so a build vendored under an unrelated project hits the crate-version fallback + warning rather than matching a far-off packages/desktop/package.json. - Register cargo:rerun-if-changed on every candidate package.json path, including nonexistent ones, so adding the file later re-stamps instead of Cargo reusing a stale fallback build. - Treat an empty "version" string as no version, so it falls through to the loud crate-version fallback rather than stamping an empty client_version. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UfUAccF8W5Prwp4BCWx7np
The `if let Some(v) = find_desktop_package_json(...).and_then(...)` one-liner formatted differently across rustfmt versions (CI's newer stable wrapped it, failing `cargo fmt --all --check`). Restructure as nested if-let blocks, which every rustfmt version formats identically. No behavior change. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UfUAccF8W5Prwp4BCWx7np
There was a problem hiding this comment.
All reported issues were addressed across 4 files (changes from recent commits).
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
Follow-up to the cubic re-review: - read_json_version now trims the JSON value and treats an empty or whitespace-only version as no version, so it falls through to the loud crate-version fallback instead of stamping an unusable client_version. - Register cargo:rerun-if-changed only for the package.json actually found, not for nonexistent candidate paths. Cargo does not reliably watch a not-yet-created file, and no real build path needs it: release builds pin the version via SEALGATE_DAEMON_VERSION (already watched) and in-tree builds always have the file present. This also simplifies the walk. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UfUAccF8W5Prwp4BCWx7np
There was a problem hiding this comment.
All reported issues were addressed across 1 file (changes from recent commits).
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Every device on the dashboard Devices page shows version
0.0.1, regardless of the actual release. The stdiod daemon announced itsclient_version(in the tunnel handshake and the device-authorization request) viaenv!("CARGO_PKG_VERSION")— but the Rust workspace version is pinned at0.0.1and never bumped per release, so every shipped daemon reported0.0.1while the desktop app is at0.6.4. The backend and dashboard were faithful; the value was wrong at the source.Reproduced end-to-end: a freshly built daemon's own
--versionprints0.0.1, and connecting devices land on the Devices page as0.0.1across macOS/Linux/Windows.Fix
Source the daemon's reported version from the desktop app's
packages/desktop/package.json— the single source of truth for the shipped release — instead of the pinned crate version.build.rsstamps the version intoenv!("SEALGATE_DAEMON_VERSION"), resolved in precedence order:SEALGATE_DAEMON_VERSIONenv var (set by the build scripts, below)packages/desktop/package.jsonlocated by walking up from the crate (zero-ceremony fallback for in-treecargo build/cargo test)CARGO_PKG_VERSION— and this last resort emits a loudcargo:warningrather than silently shipping0.0.1build-stdiod{,-win,-linux}.sh) exportSEALGATE_DAEMON_VERSIONfrompackages/desktop/package.jsonbefore invoking cargo, so shipped-release correctness never depends on build.rs locating the file.config::DAEMON_VERSION, consumed by the handshake (daemon.rs), the device-code request (auth.rs), the CLI--version(main.rs), and the corresponding test — one source of truth, no duplicatedenv!calls.serde_json(already a dependency), so a nestedversionkey can't be mistaken for the package's own.Verification
cargo build→--version0.6.4(was0.0.1)SEALGATE_DAEMON_VERSION=1.2.3-testoverride1.2.3-testcargo:warning, falls back to0.0.10.6.4cargo fmt --check,cargo clippy --workspace --all-targets -- -D warnings,cargo test --workspace, and the AI-writing check all pass.Note on existing rows
This fixes the version the daemon reports going forward. Device rows already stored as
0.0.1self-heal on the next daemon reconnect (the row is upserted on each handshake); no backfill needed.🤖 Generated with Claude Code
Generated by Claude Code
Summary by cubic
Stamp the stdiod daemon
client_versionfrom the desktop app release so Devices show the real version. Previously all devices reported0.0.1viaCARGO_PKG_VERSION; now the handshake, auth request, and CLI--versionuse the desktoppackages/desktop/package.jsonversion or an explicit override, with a loud fallback to the crate version.build.rsinsealgate-stdiodto resolve the version in order:SEALGATE_DAEMON_VERSION→packages/desktop/package.json→ crate version; bounds the search, watches only the locatedpackage.json, trims and treats empty/whitespace-only versions as absent, emits acargo:warningon fallback, and parses JSON withserde_json.DAEMON_VERSIONto the crate root and use it for the tunnel handshake, device-authorization request, and CLI via#[command(version = DAEMON_VERSION)].SEALGATE_DAEMON_VERSIONfrompackage.jsonwhile respecting a pre-set value, ensuring release builds stamp the correct version.build.rsto nestedif-letfor consistent formatting; no behavior change.Written for commit 9b3425b. Summary will update on new commits.