mirror of
https://github.com/nesquena/hermes-webui.git
synced 2026-05-25 03:00:23 +00:00
Hermes Bot
2856ee6637
Opus advisor flagged that the conflict-marker resolution from PR #1525's merge had not actually landed — static/sw.js still contained the literal <<<<<<< HEAD / ======= / >>>>>>> pr-1525 markers, which made the file fail to parse as JavaScript even though the substring-based source-string tests still passed (the __WEBUI_VERSION__ token was present, just inside the conflict block). Concrete impact pre-fix when shipped: - Service worker install handler would throw on script load - SW would never reach activated state - Old SW (from v0.50.278) would keep controlling the page indefinitely - Frontend cache-bust pathway silently broken - The INFLIGHT[sid] clear in static/sessions.js (the frontend half of PR #1525's stale-stream cleanup) would never deliver to existing browsers because the new SW would never activate Fix: - Resolve sw.js conflict to keep CACHE_NAME = 'hermes-shell-__WEBUI_VERSION__' (the post-#1517 rename, with the manual -stale-stream-cleanup1 suffix dropped as redundant — natural version-token bump invalidates old caches). - Add tests/test_pwa_manifest_sw.py::test_sw_js_has_no_merge_conflict_markers regression guard that scans for <<<<<<<, =======, >>>>>>> in sw.js source. - Update tests/test_stale_stream_cleanup.py::test_service_worker_cache_ bumped_for_frontend_fix_delivery to assert the canonical version-token CACHE_NAME pattern instead of the (now-removed) -stale-stream-cleanup1 manual suffix. 3945 → 3946 tests passing (+1 from the new conflict-marker guard). This issue would have shipped a broken service worker if Opus hadn't caught it. The new test_sw_js_has_no_merge_conflict_markers test would have flagged it earlier in the pipeline. Caught-by: Opus advisor pass on stage-279 brief Co-authored-by: ai-ag2026 <ai-ag2026@users.noreply.github.com>
