Skip to content

A local portal on current main cannot sign in or render: the Blazor login UI is deleted and the default views arrive only as registry bundles #2367

Closed
#2386
Closed
A local portal on current main cannot sign in or render: the Blazor login UI is deleted and the default views arrive only as registry bundles#2367
#2386

Description

@sierragolflima
sierragolflima
opened on Aug 26, 2026

Summary

Two independent consequences of the GUI migration leave a freshly-updated local portal unusable, and
each one presents as something other than its cause.

  1. No login UI. 83356b3d5 ("Delete Blazor and the portal GUI from core", Delete Blazor and the portal GUI from core #2293 — 389 files,
    −54,420 lines) removed Login.razor, DevLogin.razor and DevLoginConfirm.razor.
    DevAuthController survives, so POST /dev/signin still works — but nothing renders a way to
    reach it.
  2. No control views. DefaultViews and GraphViews were deliberately removed from
    Modules:Assemblies (Extract the GUI implementations from the core repo: RN app + Blazor packs move to MeshWeaver.Plugins #2169 Phase B2) and now reach a deployment only as registry bundles. An
    install that has them uninstalled renders every control as its ToString().

Both together mean a developer following LocalColimaMac.md gets a portal they cannot log into,
and — if they get in another way — cannot read.

How to reproduce

# 1. A local install on current main
memex-local up && memex-local update

# 2. No login page is served by the Blazor shell
curl -sk -o /dev/null -w "%{http_code}\n" https://memex.localhost:8443/login
#    on a build after 83356b3d5 the Blazor login route is gone

# 3. …but the sign-in endpoint still works, proving only the UI is missing
curl -sk -D - -o /dev/null -X POST https://memex.localhost:8443/dev/signin \
     -d "personId=<an existing user>"
#    HTTP 302, location: /, set-cookie: MemexAuth=…

# 4. Once signed in, controls render as text rather than UI
open https://memex.localhost:8443/Agent
#    NamedAreaControl { Id = , Style = , Readonly = , Skins = …, Area = Details, … }

# 5. The cause: no view pack is loaded
kubectl -n memex logs deploy/memex-portal-deployment | grep ModuleLoad
#    MeshWeaver.AI, MeshWeaver.Social, MeshWeaver.Hosting.Grpc, Mcp, Mail — and no views

# 6. The packages are visible but not installed
kubectl -n memex exec deploy/memex-portal-deployment -- ls /plugin-repos/Plugins/DefaultViews
#    index.json, Gallery, manifest.lock …
kubectl -n memex exec deploy/memex-portal-deployment -- ls /data/modules
#    MeshWeaver.Mcp, MeshWeaver.Mail.MicrosoftGraph — no DefaultViews, no GraphViews

Why it is not self-correcting

  • InstallByDefault seeds a fresh installation only, so an existing local mesh never picks the
    new packages up — and these packages did not exist when it was seeded.
  • The documented remedy is Settings ▸ Administration ▸ Plugin Catalog, which is rendered by the
    views that are missing. The portal cannot repair itself through its own UI.

Workaround

https://memex.localhost:8443/frontend/react → redirects to /next. The React frontend brings its
own control pack and does not depend on the Blazor view packs, so content renders there. This only
helps where portalNext is enabled, which memex-local does automatically when it can build the
image.

Suggested direction

Not a proposal for the migration itself — that is a maintainer decision. What appears to be needed:

  1. A path to install DefaultViews/GraphViews that does not require a rendered UI — a
    boot-time reconcile of preInstalled packages that also applies to EXISTING installs, or a
    memex-local subcommand.
  2. Either the Blazor login UI stays until the React frontend is the default, or the switch to React
    becomes automatic when the Blazor shell can no longer render a login.
  3. LocalColimaMac.md §9 documents a Blazor login flow that no longer exists on main.

Environment

Activity

  1. rbuergi
    added a commit that references this issue on Aug 26, 2026

    Local-dev docs: the portal hosts live in MeshWeaver.Plugins now (#2367)

    e8d591c

  2. sierragolflima commented on Aug 26, 2026

    @sierragolflima
    sierragolflima
    on Aug 26, 2026
    CollaboratorAuthor

    The React frontend has no login page either — so there is currently NO login UI at all

    Defect 1 above says the Blazor login UI was deleted. Checking whether the React frontend covers the
    gap: it does not.

    clients/portal-next (MeshWeaver.Plugins) has no login route. UserProfileMenu.tsx, LiveArea.tsx
    and ViewerLocale.tsx mention sign-in only in passing; nothing renders a login.

    The strongest evidence is the frontend's own e2e, which authenticates by posting to the
    controller and reusing the cookie rather than by driving a page —
    clients/portal-next/e2e/next-only.spec.ts, in two places:

    const login = await request.post(`${portal}/dev/signin`, { … });
…
const login = await page.request.post(`${portal}/dev/signin`, { … });

    That reframes the issue. It is not "the Blazor login was deleted a little early, and React will pick
    it up" — neither shell can log a human in on current main, and the platform's own test suite
    has already routed around the gap. A test that works around a missing surface is the point at which
    the gap stops being visible to CI: next-only is green precisely because it never needs the page.

    Practical consequence

    A developer following LocalColimaMac.md today reaches a portal with no way in from a browser. The
    workaround is an HTML form posting to /dev/signin, which is the same mechanism the e2e uses:

    <form method="post" action="https://<host>/dev/signin">
  <input name="personId" value="<username>">
  <input type="hidden" name="returnUrl" value="/">
  <button type="submit">Sign in</button>
</form>

    That works because DevAuthController survives the deletion and still issues a valid MemexAuth
    cookie — verified against a live local portal (HTTP 302, set-cookie: MemexAuth=…; secure; httponly; samesite=lax).

    What this changes about item 2

    Item 2 in the issue offers a choice between "keep the Blazor login until React is the default" and
    "switch to React automatically". Neither helps while React has no login page either. The prior
    question is which shell owns sign-in, and until that is answered and built, every new install
    needs the form above.

  3. rbuergi commented on Aug 26, 2026

    @rbuergi
    rbuergi
    on Aug 26, 2026
    Contributor

    Both root causes here were already closed by work that landed 2026-08-25, a day before this was filed — which is why the two halves read as separate mysteries. Checking both repos:

    1. The login UI was moved, not deleted. Login.razor, DevLogin.razor and DevLoginConfirm.razor live at MeshWeaver.Plugins/src/Memex.Portal.Gui/Pages/, ProjectReferenced by both Memex.Portal.Distributed and Memex.Portal.Monolith — i.e. compiled into the image memex-local builds, which already resolves $MEMEX_PLUGINS_REPO/src/Memex.Portal.Distributed (memex-local:276-281). The issue's git cat-file -e origin/main:… check looked at the core repo only.

    2. The view packs already reconcile on every boot. Both DefaultViews/index.json and GraphViews/index.json declare "preInstalled": true (plugins 9b634584, 2026-08-25). PluginCatalog:InstallPreInstalledPackages defaults true and is reconciled on EVERY boot — explicitly exempt from the seed ledger, and built for exactly "a package newly added to the repo" plus healing a lost baseline (#902). InstallByDefault's once-only semantics, which this issue reasoned from, are the other knob. #2221/#2224 (the registry shelf dropping every pack's wwwroot) also merged 2026-08-25.

    So the bootstrap question this issue poses answers itself, both ways: the login UI is genuinely shell and ships in the image; the views are genuinely a pack and the default install lands them on every boot, fresh install or existing. No scope decision needed.

    What was actually left is the third possibility in the issue — the tooling and docs no longer match reality, and nothing guarded either. #2386:

    • memex-local's verify_endpoint could not fail: it judged curl's exit code, not the code it fetched. Measured on this machine — curl … https://memex.localhost:8443/ → http=503, exit 0 → ok "Portal reachable". And update never called it at all. That is the whole of "both printed ok and the portal was unusable". Replaced with a check that asserts the portal serves, that /login is routed, and that both view-pack modules are present, each naming its remedy — waiting on [DefaultInstall] reconciled rather than a stopwatch, and performing the one activation restart itself where the packs are landed with .pending-restart. up/update refuse to report success without it; memex-local verify asks it any time.
    • Two more live defects surfaced while proving the new check can fail: memex-local help was an unbounded fork bomb (a backtick in an unquoted heredoc re-entered main()), and helm_deploy aborted on macOS bash 3.2 for the paths the script itself calls normal (set -u + an empty "${array[@]}", which every --from-acr run hits).
    • None had ever gone red because nothing in CI had ever opened this ~2000-line script. It is now parsed, linted and behaviour-tested on every build.
    • LocalColimaMac.md §3/§9/§12/§14 corrected — it still pointed at memex/aspire/Memex.Portal.Distributed and src/MeshWeaver.Blazor.Portal, and its §14 "verify end-to-end" was the curl that could not fail. (Local-dev docs: the portal hosts live in MeshWeaver.Plugins now (#2367) #2380 covers the other twelve docs and does not touch this file.)

    🚨 Not verified: a full memex-local up end-to-end — the local stack here is degraded (portal at 0/0, portal-next in ImagePullBackOff) and a full publish+deploy is long and disruptive on this machine. The in-pod probe is proven against stubs and against a real kubectl exec on the real cluster (which correctly reported the portal unreadable and exited 1 with all three remedies), but not against a running portal pod; its command shape is identical to this issue's own diagnostic. If a real bring-up disagrees, the new check now names which of the three failed and why.

  4. rbuergi
    closed this as completedin #2386on Aug 26, 2026
  5. rbuergi
    added 3 commits that reference this issue on Aug 26, 2026

    Merge pull request #2386 from Systemorph/fix/2367-local-portal-usable…

    f494f65

    Local-dev docs: the portal hosts live in MeshWeaver.Plugins now (#2367)

    d9f178a

    Merge pull request #2380 from Systemorph/fix/2367-local-dev-docs-port…

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions