Feature request: a versioning indicator so users can verify a deployment is up to date #956

Activity

1. rbuergi

   closed this as completedin #1006on Aug 9, 2026
2. sierragolflima commented on Aug 10, 2026

   

   sierragolflima

   on Aug 10, 2026

   CollaboratorAuthor

   More actions

   Follow-up: the underlying build-currency fix in this issue is correct, but its own
   entry points — "About" and "What's New" from the profile menu — currently 404 for
   what looks like an unrelated code defect, independent of any deployment question.

   Repro

   Click the profile/account avatar top-right (not Settings — see "Where this is meant
   to live" below), then About or What's New. The page loads with:

   Page not found: '_settings/GlobalSettings/WhatsNew' does not match any registered
   address pattern.

   (Note: that message named WhatsNew even when the address bar showed .../About —
   possibly a separate stale-error-display issue, not chased further here.)

   Likely cause

   • The registered mesh node lives at path _Setting — singular, capital S
     (GlobalSettingsNodeType.SettingsPath, src/MeshWeaver.Graph/Configuration/GlobalSettingsNodeType.cs:21).
   • The profile-menu navigation hardcodes _settings — plural, lowercase
     (UserProfile.razor.cs:170,172, src/MeshWeaver.Blazor.Portal/Components/UserProfile.razor.cs):

     private void NavigateToWhatsNew() => Navigation.NavigateTo("/_settings/GlobalSettings/WhatsNew");
     private void NavigateToAbout() => Navigation.NavigateTo("/_settings/GlobalSettings/About");

   • _settings (lowercase) is otherwise used elsewhere in the codebase as a reserved
     satellite/schema segment name in the cross-schema Postgres/Snowflake routing — an
     unrelated meaning — not as an alias for this node.

   If the mesh path resolver is case/spelling-sensitive here (as a related fixed bug —
   PgOnlyProdShapeTests.ResolvePath_AreaSuffixOnExistingPartition_FallsBackToMainNode
   — suggests it is for adjacent shapes), this mismatch alone would 404 on any
   deployment, current or not. Not confirmed by running the app locally, so flagging as
   a strong lead rather than a proven root cause.

   Where this is meant to live — worth clarifying regardless of the above

   Separately from the routing bug: it took real back-and-forth to find "About" at all,
   because the naming is inconsistent about where it belongs:

   • This issue's own originating PR (The About page shows the platform build AND every installed plugin #897) describes it as "Settings → About."
   • The code calls it AddAboutSettingsTab(), grouped in a long chain of
     Add*SettingsTab() calls alongside ApiTokens, Instances, Notifications, etc.
     — all of which render in the per-user Settings navigation tree
     (Home > {user} > Settings).
   • But About/What's New actually register as GlobalSettings items, surfaced
     only from the profile/account menu (top-right avatar) — a separate page
     entirely from that Settings tree, at a different URL shape
     (/_settings/GlobalSettings/{tabId} vs. the per-user tree's own routing).

   Every other tab named alongside it in the source (AddPrivacySettingsTab,
   AddInvitationsSettingsTab, AddTokenUsageSettingsTab, etc.) is also a
   GlobalSettings item, not a per-user Settings tab — so this isn't unique to
   About/What's New, but it means the "Settings" framing in both the PR description and
   the code's own naming actively points a reader at the wrong navigation surface.
   Worth either renaming for clarity or adding a visible link between the two pages.
3. sierragolflima commented on Aug 18, 2026

   

   sierragolflima

   on Aug 18, 2026

   CollaboratorAuthor

   More actions

   Follow-up to my earlier comment on this issue: the routing defect described there is now
   tracked properly as #1817, so it is findable outside a closed issue's comment thread.

   Two things changed since that comment:

   1. It spread. Show which build — and which instance — is serving the session #1791 (the top-bar build chip) added a third call site with the same
      hardcoded /_settings/… literal, so the About page is now unreachable from the chip as
      well as from the two profile-menu entries. That is the reason it is worth its own issue —
      it keeps propagating because the literal is repeated rather than derived from
      GlobalSettingsNodeType.SettingsPath.

   2. This issue's original ask is no longer blocked by it. Show which build — and which instance — is serving the session #1791's chip reports the running
      build (and the serving instance) persistently in the header, without navigating anywhere.
      So "can a user verify the deployment is current?" — the question this issue was filed for —
      is answered today, even though the About page it originally shipped on still 404s.

   Nothing here asks to reopen #956; the fix it requested did ship (#985, #1006). Recording the
   pointer so anyone arriving here from the About page follows it to the live defect.
4. rbuergi commented on Oct 11, 2026

   

   rbuergi

   on Oct 11, 2026

   Contributor

   More actions

   (re-posted 2026-10-11; originally by @rbuergi on 2026-08-09)

   Assessment: mostly built — two named gaps

   Checked origin/main @ c6607346e. It helps to split the request in two: "what build is this?" and "is that build current?". The first is fully shipped and visible to every user; the second exists but only for platform admins.

   Already shipped

   Build identity is baked in at compile time. Directory.Build.props → target AddCommitHashMetadata stamps the git SHA into every assembly as AssemblyMetadata("CommitHash"), sourced from the SDK's SourceRevisionId and falling back to GITHUB_SHA. It is deliberately kept off InformationalVersion because CI overwrites that with $(Version)+build.<ticks>, which drops the SDK's default +<sha> suffix. Version itself is 3.0.0-rc1.ci.$(GITHUB_RUN_NUMBER). So the raw material is in the image with no runtime plumbing needed.

   The About tab already surfaces it, ungated. memex/Memex.Portal.Shared/Settings/AboutSettingsTab.cs, registered at memex/Memex.Portal.Shared/MemexConfiguration.cs:915 (.AddAboutSettingsTab()). It renders Version, Build commit (as a link to the exact GitHub commit via ShippedReleaseSeed.CommitUrl), Repository, Runtime, and the live installed-plugin inventory. There is no permission gate — GetTab returns the definition unconditionally, unlike UpdatePolicySettingsTab / InvitationsSettingsTab, which filter on AdminMenuGate.IsPlatformAdmin. Localization keys are present (src/MeshWeaver.Messaging.Hub/Localization/strings.en.json:196-209 and :538).

   There is also a machine-readable copy. ShippedReleaseSeed.EnsurePlatformVersionNode writes the running version to the Admin/PlatformVersion mesh node at startup. The native client already consumes it: memex/Memex.Client/Services/UpdateNotificationService.cs reads a remote mesh's Admin/PlatformVersion and alerts when the remote is newer than the bundled build.

   "Is it up to date" is answered — for admins. memex/Memex.Portal.Shared/Settings/UpdatePolicySettingsTab.cs shows Running version + Latest available tag + when last checked, plus an "apply now" button. Those two bookkeeping fields (UpdatePolicyContent.LatestAvailableTag / CheckedAt) are written by the ACR poller at memex/Memex.Portal.Shared/SelfUpdate/SelfUpdateHostedService.cs:175.

   The actual gaps

   1. The running-vs-latest comparison is platform-admin only. UpdatePolicySettingsTab.GetTab gates on AdminMenuGate.IsPlatformAdmin (UpdatePolicySettingsTab.cs:45-48). A normal user gets About — what build is running — but no surface telling them whether that build is current. The issue asks for "users ... verify a deployment is up to date", and that half is admin-only.
   2. Nothing is reachable without an authenticated Blazor session. /health and /alive (memex/aspire/Memex.Portal.ServiceDefaults/ServiceDefaults.cs:111,114) carry no version, and there is no /api/version (grepped MapGet/MapPost across src/ and memex/ — nothing). So verifying from outside still requires logging in.

   On the observation in the report

   The About tab was in the deployed code. I checked 1af1aaa84 directly: AddAboutSettingsTab() is present at MemexConfiguration.cs:891. So "the code wasn't in that image" does not explain a missing tab on ci.1842.

   However, the deployment has rolled forward twice since the report was filed. Current state:

   memex-cloud   memex-portal-deployment   meshweaver.azurecr.io/memex-portal-ai:3.0.0-rc1.ci.2340
   memex         memex-portal-deployment   meshweaver.azurecr.io/memex-portal-ai:3.0.0-rc1.ci.2340
   client-i         memex-portal-deployment   meshweaver.azurecr.io/memex-portal-ai:3.0.0-rc1.ci.2151
   

   In ACR, 3.0.0-rc1.ci.2340, c660734 and main are the same manifest digest (sha256:7d532f06…), and c660734 is current origin/main HEAD.

   So: worth re-checking Settings → About on memex.meshweaver.cloud before anyone chases a rendering bug. If the tab is there now, the original observation was against the older image and only the two gaps above remain. If it is still absent on ci.2340, that is a separate live defect and deserves its own issue — the registration is unconditional, so an absent tab would mean something is interrupting hub configuration, not a missing feature.

   (One structural note on the report's method: the About tab is the thing that tells you the build, so its absence can never itself be read as evidence of staleness.)

   Smallest honest implementation

   Add the running-vs-latest line to the About tab, which is already ungated and already renders ShippedReleaseSeed.InstalledPlatformVersion. The comparison values already exist on Admin/UpdatePolicy (LatestAvailableTag + CheckedAt) — no new state, no new poller.

   The one design decision this forces: Admin/UpdatePolicy lives in the Admin partition, so a normal user most likely cannot read it. I did not verify a non-admin read against a live mesh, so treat that as the open question rather than settled. Two ways out:

   • (a) mirror the poller's finding onto a node ordinary users can read, or
   • (b) have the About tab read it as System and render only the derived string ("up to date" / "update available: X"), never the policy node itself.

   (b) is smaller and leaks less.

   If an out-of-band check is also wanted, a MapGet("/api/version") returning {version, commit} is a few lines and needs no new state — but that is a separate, additive decision, not required by the above.

   Recommendation

   Keep open, but retitled around the real remainder rather than the original premise. Two named items:

   • Running-vs-latest is admin-gated — surface it on the ungated About tab.
   • No unauthenticated version surface — decide whether /api/version is wanted.

   Everything else this issue asks for — version, git commit, GitHub link, visible to every user — is on main today.