Sync upstream/main (96 commits) - #2
Conversation
૮ >ﻌ< ა ci reviewrunning on 5aa73db — Sync upstream/main (96 commits) waiting for jobs to start… |
randlee
left a comment
There was a problem hiding this comment.
Contessa Review — Fork Sync PR #2
CI Results
| Check | Status |
|---|---|
| Python tests (11/12 slices) | ✅ Pass |
| Python tests (slice 3/12) | ❌ FAIL |
| JS/TS checks (all) | ✅ Pass |
| Python lints | ✅ Pass |
| Docs checks | ✅ Pass |
| Installer tests | ✅ Pass |
| Supply-chain scan | ✅ Pass |
Failing Test
tests/gateway/test_multiplex_busy_input_mode.py::test_profile_route_and_nonmultiplexed_resolution_preserve_boundaries
AssertionError: assert 'interrupt' == 'steer'
Root cause: Rejecting profile route 'research-chat': target profile 'research' is not served
Analysis
- This is an upstream bug, not fork-introduced. The test file was created in upstream commit
a31be4803("fix(gateway): respect routed profile busy modes"). The same test fails onNousResearch/hermes-agent/main. - 14 of 15 tests in that file pass; 1 assertion is wrong in a profile routing boundary check.
- The merge itself is clean: 212 files, no conflicts, no manual resolution needed.
Verdict: NEEDS_FIX — test failure in upstream code
- Does NOT block merge — the fork faithfully mirrors upstream state including this known bug.
- Recommend: merge as-is and track upstream fix. The test failure exists in CI on NousResearch/hermes-agent too.
randlee
left a comment
There was a problem hiding this comment.
Alpha-Prime Review — PR #2
Investigation of test failure
Failing test: test_profile_route_and_nonmultiplexed_resolution_preserve_boundaries
Root cause analysis: The test at line 339 expects _effective_busy_input_mode(source) to return "steer" (from the research profile snapshot), but it returns "interrupt" (the default). The call chain:
_effective_busy_input_mode→_busy_profile_name_for_source→_profile_name_for_source_profile_name_for_sourcematches the route forresearch-chat→ profile"research"- It then checks if
"research"is in the served-profiles set (line 25429:_multiplex_profile_homes(config)) - Since
"research"is NOT served →ProfileRouteRejected→ caught → returns None - Fallback:
"interrupt"is used
The test needs runner.config.multiplex_profile_homes (or whatever _multiplex_profile_homes reads) to include "research". The test author only called _snapshot_profile_busy_modes but didn't configure the profile as served.
Decision: NO FIX IN FORK
This is an upstream bug in commit a31be4803. The same test fails on NousResearch/hermes-agent/main. Fork-sync must faithfully mirror upstream — fixing upstream bugs here creates merge divergence.
Recommendation: Merge as-is. The fork correctly reflects upstream state. The test failure is cosmetic (1 of 15 tests in a new file, does not affect functionality). File upstream issue if desired.
|
Superseded: the fork now syncs via REBASE (main = upstream/main + 1 fork patch) instead of merge-based sync. This merge PR was a stale balloon. Closing. |
Two independent bugs let a deleted profile reappear / leave orphaned resources on next launch: 1. hermes_cli/profiles.py's backend-process scanner required argv[0] to resolve to an executable literally named "hermes". Electron's pool-backend spawn resolves the hermes console-script shim's path and execs it via the interpreter directly (python3 /path/to/hermes ...), so argv[0] reports as "python3" and the scanner never matched the running backend -- delete removed the profile's files but left its live backend process running (still bound to a port via uvicorn), which accumulates across repeated delete/recreate cycles. 2. The desktop sidebar's ProfileRail only refreshed its cached profile list once, on mount, so a delete/create/rename from another surface (another window, or the CLI) left a stale ghost entry until something unrelated triggered a refetch. Note: a delete via this window's own Manage-Profiles view already refreshes the shared $profiles atom ProfileRail subscribes to (confirmed by reading refreshProfiles() and handleConfirmDelete()) -- this fix only covers the cross-window/cross- process staleness gap, not a duplicate of the already-merged NousResearch#57329's Manage-Profiles rail-refresh work. Fix 1: recognize a python-interpreter argv[0] exec'ing a hermes-named console-script shim via argv[1]. Fix 2: refresh the profile list on window focus/visibilitychange, matching the existing pattern used elsewhere in the sidebar (sidebar/index.tsx, use-background-sync.ts, star-map.tsx, use-gateway-boot.ts all use the same focus+visibilitychange pattern). ## Related work already on main PR NousResearch#57329 (merged) fixed the *headline* symptom from issue NousResearch#52279 (deleted profile respawns) via a different, non-overlapping mechanism: routing profile-delete through the primary backend instead of spawning a fresh pool backend, plus a separate recreation guard in ensure_hermes_home() (NousResearch#49435, merged) that makes a backend spawned into a deleted profile's directory raise FileNotFoundError instead of silently recreating it. This PR is NOT a duplicate of that fix. Verified: even with both of those merged, a backend process that survives because of gap #1 above still holds a bound port via uvicorn -- it just can no longer resurrect the profile directory. That's real resource-hygiene, not a symptom already covered. Gap #2 touches a different file/component (ProfileRail / profile-switcher.tsx) than NousResearch#57329's rail-refresh half (which touched the Manage-Profiles view's own $profiles.ts / index.tsx) and covers a distinct staleness path (cross-window/cross-process, not same-window delete-then-refresh). Tests: tests/hermes_cli/test_profiles.py -- 156 passed (existing + regression coverage for the argv[0] python-interpreter detection case). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Automated fork sync: merge upstream/main (NousResearch/hermes-agent) into randlee/hermes-agent.
Changes: 212 files changed, +16,045 / -2,929
Key changes from upstream:
Generated by: grecon fork-sync pipeline