fix: re-enable model version CI check (prevents stale MODEL_VERSION in desktop builds)#10796
Merged
ArtyomSavchenko merged 1 commit intoApr 23, 2026
Conversation
The check_model_version.js CI step was commented out, which allowed v0.7.413 to ship with MODEL_VERSION=0.7.343 baked into the desktop client. This causes a blocking "New version is available" dialog for self-hosted users whose servers have MODEL_VERSION > 0.7.343. Re-enabling this check will catch future model/version.txt drift before it reaches a release. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
Connected to Huly®: UBERF-16344 |
ArtyomSavchenko
approved these changes
Apr 23, 2026
Member
|
@shanzez Thank you for the contribution. |
ArtyomSavchenko
approved these changes
Apr 23, 2026
7905e0a
into
hcengineering:develop
12 of 13 checks passed
Member
|
@shanzez @ArtyomSavchenko FYI Disable again In #10804 We need this check only if migration changed |
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.
Summary
Re-enables the
check_model_version.jsCI step that was commented out inmain.yml. This check verifies thatcommon/scripts/version.txtis updated whenever files inmodels/change, preventing staleMODEL_VERSIONvalues from being baked into desktop client builds.Problem: v0.7.413 desktop client is broken for self-hosted users
The Mac arm64 desktop client v0.7.413 (downloaded from https://huly.io/download) ships with
MODEL_VERSION=0.7.343baked in via webpack DefinePlugin. When a self-hosted Huly server hasMODEL_VERSION > 0.7.343(e.g. 0.7.410), the desktop client shows a blocking "New version is available" dialog (0.7.410 => 0.7.343) and refuses to connect.This was reported in the Huly Discord by a self-hosted user running on a MacBook Pro M4. The Huly team confirmed the issue does not reproduce against
huly.app(because the cloud server's MODEL_VERSION matches what the client expects), but it does reproduce against any self-hosted instance where the data model has advanced beyond 0.7.343.Tested fix: Patching
MODEL_VERSIONfrom0.7.343to0.7.410in the bundledelectron.jsinsideapp.asarresolves the issue. The desktop client connects to a self-hosted server (v0.7.413, MODEL_VERSION=0.7.410) without showing the version dialog. Verified on macOS arm64 (MacBook Pro M4).Root Cause Analysis
How MODEL_VERSION flows into the desktop build
How the version check works at runtime
start.ts) returns bundledMODEL_VERSIONvia IPC (GetMainConfig)preload.ts:113) explicitly overrides server config with bundled value:platform.ts:377) setspresentation.metadata.ModelVersionto this valueHow the stale version shipped
The git history at the
v0.7.413tag tells the story:42f2141d0963233b81developto0.7.410("Card grid #10749") - not merged into release branch3d469f0108c6d8a24cThe model changes that bumped the server's MODEL_VERSION to 0.7.410 on
develop(Card grid, Card versioning, RBAC, etc.) got into the server Docker images butversion.txton the release branch was never updated to match. Thecheck_model_version.jsCI step that would have caught this was commented out.Why this only affects self-hosted
The Fix
Immediate (already on develop and staging-new)
version.txthas been updated to"0.7.410"on both branches, so the next release will have the correct MODEL_VERSION. A patch release (v0.7.414) for the current broken build would be appreciated by self-hosted users.Prevention (this PR)
Re-enables the
check_model_version.jsCI step that validatesversion.txtis bumped whenmodels/changes. This was the safety net that would have caught the drift before release.Workaround for affected users
Until a new release ships, self-hosted users on macOS can patch their installed client:
Replace
0.7.410with your server'sMODEL_VERSION(visible athttps://your-huly-instance/config.json).