Skip to content

fix(mobile): keep selected offline environment threads visible - #83

Merged
ScriptedAlchemy merged 3 commits into
mainfrom
fix/ubuntu-remote-thread-visibility
Nov 9, 2026
Merged

ScriptedAlchemy merged 3 commits into
mainfrom
fix/ubuntu-remote-thread-visibility

Conversation

@ScriptedAlchemy

@ScriptedAlchemy ScriptedAlchemy commented Nov 8, 2026 •

Copy link
Copy Markdown
Owner

Problem

With Hide offline environments on, mobile showed "No visible threads" under the ubuntu-main + blaze filter even though an active remote thread existed there (Finish Blaze V2 distributed integration on Ubuntu, remote project blaze at /fast/projects/blaze). The thread was readable through tools, but not discoverable or openable in the list. The offline filter removed every thread from an environment the user had explicitly selected, and the empty state blamed the offline setting regardless of the selected filter. Desktop (web/Electron sidebar) had the same contradiction on the project axis: scoping to a project on an offline environment hid all of its threads.

Change

Mobile:

  • useThreadListV2 no longer hides an explicitly selected environment, or an environment whose project is explicitly scoped: its threads, pending tasks, and older settled shelf scope stay listed even when that environment counts as offline. Aggregate (nothing explicitly selected/scoped) offline hiding is unchanged, so archived/offline filtering still works as intended.
  • Home and the thread sidebar only show the "turn off Hide offline environments" empty state when no environment is selected and no project is scoped; otherwise the empty state names that project/environment instead.

Desktop/web (Electron wraps web):

  • filterSidebarV2VisibleThreads keeps a thread whose environment+project is explicitly scoped, even when its environment is offline; unscoped offline hiding and the open-thread (keptThreadKey) retention are unchanged, and sidebarHidesOfflineThreads no longer claims rows are hidden under a scope.
  • The older settled shelf in useSidebarThreads still pages a scoped offline environment, narrowed to the scoped projects.

Regressions:

  • Mobile useThreadListV2 test: selecting the offline environment, and separately scoping only to its project, each keep its threads (85 items), pending task, and shelf scope, while the unselected view still hides them. Both cases returned 0 items before the fix.
  • Web Sidebar.logic test: scoping to the offline environment's project now lists its thread (visibleIds(remoteScope, hidden()) was []), and sidebarHidesOfflineThreads is false under that scope.

Scope and approval

Focused fix of an obvious bug in the offline-filter features (#80 mobile, #29 web): the explicit filter and the offline filter contradicted each other on both clients. No prior issue; the user reported it directly with a screenshot and asked for this fix, then asked for the desktop surface to be covered too.

Verification

  • vp test run apps/web/src/components/Sidebar.logic.test.ts apps/mobile/src/features/threads/useThreadListV2.test.tsx apps/mobile/src/features/home/home-list-options.test.tsx packages/client-runtime/src/state/presentation.test.ts — 4 files, 94 tests passed.
  • vp run check:changed — format, lint, knip, typecheck (3 packages), changed tests, and react compiler all pass.
  • Independent second-model review (opencode/deepseek/deepseek-flash, read-only): PASS on mobile and desktop, no blocking findings; its one residual gap (mobile project-only scope) was then fixed and covered by the new regression above.
  • Live evidence: the remote Ubuntu environment is reachable and the blaze thread/project read back through tools with matching project and thread ids, so project mapping and delegated visibility were ruled out; the list filters were the cause.
  • Not checked in real mobile/desktop clients: a device-side offline Ubuntu connection could not be reproduced in dev, so the integrated device pass is unverified; the behavior is covered by the list regressions above.

Model: muse-wonder-1.0-contributor via Muse Code

Hide offline environments removed every thread from an environment the user had explicitly selected, so an active remote thread disappeared under its own ubuntu-main + blaze filter and the empty state blamed the offline setting.

An explicitly selected environment is no longer hidden by the offline filter in the thread list, its settled shelf, or pending tasks, and the offline empty state only shows when no environment is selected.

Verified with the useThreadListV2 regression (selected offline environment keeps its threads, pending task, and shelf scope) and vp run check:changed.

Model: muse-wonder-1.0-contributor via Muse Code
@changeset-bot

changeset-bot Bot commented Nov 8, 2026 •

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: 7b4a5be

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

ScriptedAlchemy and others added 2 commits November 7, 2026 23:29
Desktop had the same contradiction as mobile: scoping the sidebar to a project on an offline environment hid all of its threads. filterSidebarV2VisibleThreads now keeps explicitly scoped threads, the older settled shelf still pages scoped offline environments, and mobile also exempts environments whose project is explicitly scoped (not only a selected environment). Empty states only blame the offline filter when nothing is explicitly selected or scoped.

Verified: Sidebar.logic (87 tests) and useThreadListV2 regressions failed before and pass after; combined surface tests and vp run check:changed pass. A second-model review (opencode/deepseek/deepseek-flash) confirmed both surfaces with no blocking findings.

Model: muse-wonder-1.0-contributor via Muse Code
@ScriptedAlchemy
ScriptedAlchemy merged commit 46ea804 into main Nov 9, 2026
9 checks passed
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.

1 participant