Skip to content

fix: re-enable model version CI check (prevents stale MODEL_VERSION in desktop builds)#10796

Merged
ArtyomSavchenko merged 1 commit into
hcengineering:developfrom
shanzez:fix/re-enable-model-version-check
Apr 23, 2026
Merged

fix: re-enable model version CI check (prevents stale MODEL_VERSION in desktop builds)#10796
ArtyomSavchenko merged 1 commit into
hcengineering:developfrom
shanzez:fix/re-enable-model-version-check

Conversation

@shanzez

@shanzez shanzez commented Apr 22, 2026

Copy link
Copy Markdown
Contributor

Summary

Re-enables the check_model_version.js CI step that was commented out in main.yml. This check verifies that common/scripts/version.txt is updated whenever files in models/ change, preventing stale MODEL_VERSION values 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.343 baked in via webpack DefinePlugin. When a self-hosted Huly server has MODEL_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_VERSION from 0.7.343 to 0.7.410 in the bundled electron.js inside app.asar resolves 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

common/scripts/version.txt
  -> show_version.js (reads version.txt, outputs value)
    -> desktop-package/package.json dist scripts:
        MODEL_VERSION=$(node ../common/scripts/show_version.js)
      -> desktop/webpack.config.js DefinePlugin:
          'process.env.MODEL_VERSION': JSON.stringify(process.env.MODEL_VERSION)
        -> baked into dist/main/electron.js as literal string

How the version check works at runtime

  1. Electron main process (start.ts) returns bundled MODEL_VERSION via IPC (GetMainConfig)
  2. Preload script (preload.ts:113) explicitly overrides server config with bundled value:
    MODEL_VERSION: mainConfig.MODEL_VERSION,  // always uses bundled, ignores server
  3. Platform UI (platform.ts:377) sets presentation.metadata.ModelVersion to this value
  4. Workbench compares this against the server's actual data model version
  5. If server model > client model, a blocking "New version is available" dialog appears

How the stale version shipped

The git history at the v0.7.413 tag tells the story:

Commit Date What happened
42f2141d0 2026-01-10 Last model version bump on the release branch (version.txt set during "Add type/tag permissions")
963233b81 2026-04-12 Model version bump on develop to 0.7.410 ("Card grid #10749") - not merged into release branch
3d469f010 2026-04-14 11:43 @armisav commits "Fix model version" (0.7.343 -> 0.7.413)
8c6d8a24c 2026-04-14 13:35 @armisav reverts his own fix 2 hours later (0.7.413 -> 0.7.343)
v0.7.413 tag 2026-04-14 Tagged on the revert commit - ships with MODEL_VERSION=0.7.343

The 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 but version.txt on the release branch was never updated to match. The check_model_version.js CI step that would have caught this was commented out.

Why this only affects self-hosted

  • huly.app (Huly cloud): The cloud server's MODEL_VERSION presumably matches what the client expects, so no mismatch
  • Self-hosted: Server MODEL_VERSION advances with Docker image upgrades (e.g. to 0.7.410), but the client is stuck at 0.7.343

The Fix

Immediate (already on develop and staging-new)

version.txt has 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.js CI step that validates version.txt is bumped when models/ changes. This was the safety net that would have caught the drift before release.

Note: The current check only watches the models/ directory. Some model version bumps on develop came from changes outside models/ (card RBAC, permissions, migrations). A more robust check might compare version.txt against the server's reported MODEL_VERSION or validate version monotonicity across branches.

Workaround for affected users

Until a new release ships, self-hosted users on macOS can patch their installed client:

# Extract, patch, repack
npx @electron/asar extract /Applications/Huly.app/Contents/Resources/app.asar /tmp/huly-fix
sed 's/MODEL_VERSION:"0\.7\.343"/MODEL_VERSION:"0.7.410"/' \
  /tmp/huly-fix/dist/main/electron.js > /tmp/huly-fix/dist/main/electron.js.tmp
mv /tmp/huly-fix/dist/main/electron.js.tmp /tmp/huly-fix/dist/main/electron.js
npx @electron/asar pack /tmp/huly-fix /Applications/Huly.app/Contents/Resources/app.asar

# Re-sign and remove quarantine
codesign --remove-signature /Applications/Huly.app
codesign -s - --force --deep /Applications/Huly.app
xattr -rd com.apple.quarantine /Applications/Huly.app

Replace 0.7.410 with your server's MODEL_VERSION (visible at https://your-huly-instance/config.json).

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>
@huly-github-staging

Copy link
Copy Markdown

Connected to Huly®: UBERF-16344

@ArtyomSavchenko

Copy link
Copy Markdown
Member

@shanzez Thank you for the contribution.

@ArtyomSavchenko ArtyomSavchenko merged commit 7905e0a into hcengineering:develop Apr 23, 2026
12 of 13 checks passed
@BykhovDenis

BykhovDenis commented Apr 26, 2026

Copy link
Copy Markdown
Member

@shanzez @ArtyomSavchenko FYI Disable again In #10804 We need this check only if migration changed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants