Phase 1 — WebSocket Backend + Static File Serving #236

Closed
opened 2026-07-15 11:38:47 +00:00 by Mark · 5 comments
Owner

Phase 1: WebSocket Backend + Static File Serving

Goal: Extend the Flask HTTP entrypoint with WebSocket support (Flask-SocketIO) for real-time bidirectional messaging, and serve static frontend files.

Approach candidates:

  • Add Flask-SocketIO to runtime/http_entrypoint.py — already a dependency, natural fit with existing Flask app
  • Add EventSource (SSE) endpoint as lighter alternative — simpler but unidirectional, less suitable for interactive chat
  • Standalone WebSocket server as a separate process — cleaner isolation but more operational overhead

Outputs:

  • runtime/ws_handler.py — WebSocket/SocketIO event handlers for chat messaging
  • runtime/static/ — directory for frontend static files, served by Flask
  • cli/web.py or cli/commands/web.py — optional CLI entrypoint to start web server
  • Tests in tests/unit/test_ws_handler.py

Acceptance criteria:

  • WebSocket connection established from browser to mesh backend
  • Messages sent from browser are received by the backend and routed as mesh intents
  • Response intents are streamed back to the browser in real-time
  • Existing REST API endpoints remain unaffected
  • Static frontend files served correctly via Flask
  • SocketIO event handlers tested: connect, disconnect, message, error
  • Graceful reconnection handling on disconnect

Files touched: runtime/http_entrypoint.py (amend — add SocketIO), runtime/ws_handler.py (create), runtime/__init__.py (amend), runtime/static/ (create), tests/unit/test_ws_handler.py (create), pyproject.toml (verify flask-socketio is listed)



Decomposed from mesh-seed#133

## Phase 1: WebSocket Backend + Static File Serving **Goal:** Extend the Flask HTTP entrypoint with WebSocket support (Flask-SocketIO) for real-time bidirectional messaging, and serve static frontend files. **Approach candidates:** - Add Flask-SocketIO to `runtime/http_entrypoint.py` — already a dependency, natural fit with existing Flask app - Add EventSource (SSE) endpoint as lighter alternative — simpler but unidirectional, less suitable for interactive chat - Standalone WebSocket server as a separate process — cleaner isolation but more operational overhead **Outputs:** - `runtime/ws_handler.py` — WebSocket/SocketIO event handlers for chat messaging - `runtime/static/` — directory for frontend static files, served by Flask - `cli/web.py` or `cli/commands/web.py` — optional CLI entrypoint to start web server - Tests in `tests/unit/test_ws_handler.py` **Acceptance criteria:** - [ ] WebSocket connection established from browser to mesh backend - [ ] Messages sent from browser are received by the backend and routed as mesh intents - [ ] Response intents are streamed back to the browser in real-time - [ ] Existing REST API endpoints remain unaffected - [ ] Static frontend files served correctly via Flask - [ ] SocketIO event handlers tested: connect, disconnect, message, error - [ ] Graceful reconnection handling on disconnect **Files touched:** `runtime/http_entrypoint.py` (amend — add SocketIO), `runtime/ws_handler.py` (create), `runtime/__init__.py` (amend), `runtime/static/` (create), `tests/unit/test_ws_handler.py` (create), `pyproject.toml` (verify flask-socketio is listed) --- --- _Decomposed from [mesh-seed#133](https://forgejo.tail018ac4.ts.net/Mark/mesh-seed/issues/133)_
Mark changed title from Decompose: CONV-003: Web Chat Interface — Phase 1: WebSocket Backend + Static File Serving to Phase 1 — WebSocket Backend + Static File Serving 2026-07-15 11:39:35 +00:00
Author
Owner

QA Verification — re-open / re-file required

The kanban fixit task for this issue reached done status, but no code change was actually landed. This is a reconciliation phantom, not a real fix.

Findings

  • Fixit card t_3f6b4d24 on the kanban fixit board was BLOCKED by kilo-gsd.py exited with code 1 at preflight (run 370, 2026-04-23).
  • The card sat in blocked for ~180 hours, then the janitor marked it done after the unclassified-blocked-Nh auto-escalation rule — but this is a status cleanup, not a work-completion signal.
  • Current state of master on Forgejo and in the local checkout:
    • runtime/http_entrypoint.py exists (last touched 2026-04-23, pre-issue)
    • runtime/ws_handler.py — does not exist
    • runtime/static/ — does not exist
    • tests/unit/test_ws_handler.py — does not exist
    • flask-socketio is listed in pyproject.toml (already a dep) but no SocketIO integration exists
  • No branch matching mesh-seed-236 exists; no commits reference this issue in any branch.

Conclusion

  • This issue remains open on Forgejo because the work was never attempted successfully.
  • The "done" status on the kanban fixit board is a reconciliation artifact, not a delivery signal.
  • A new fixit task has been filed on the kanban fixit board to re-attempt the implementation.

Acceptance criteria remaining (all unchecked)

  • WebSocket connection established from browser to mesh backend
  • Messages sent from browser are received by the backend and routed as mesh intents
  • Response intents are streamed back to the browser in real-time
  • Existing REST API endpoints remain unaffected
  • Static frontend files served correctly via Flask
  • SocketIO event handlers tested: connect, disconnect, message, error
  • Graceful reconnection handling on disconnect

QA verification complete. The new fixit card will track the actual implementation.

## QA Verification — re-open / re-file required The kanban fixit task for this issue reached `done` status, but **no code change was actually landed**. This is a reconciliation phantom, not a real fix. ### Findings - Fixit card `t_3f6b4d24` on the kanban fixit board was BLOCKED by `kilo-gsd.py exited with code 1` at preflight (run 370, 2026-04-23). - The card sat in `blocked` for ~180 hours, then the janitor marked it `done` after the `unclassified-blocked-Nh` auto-escalation rule — but this is a status cleanup, not a work-completion signal. - Current state of `master` on Forgejo and in the local checkout: - `runtime/http_entrypoint.py` exists (last touched 2026-04-23, pre-issue) - `runtime/ws_handler.py` — **does not exist** - `runtime/static/` — **does not exist** - `tests/unit/test_ws_handler.py` — **does not exist** - `flask-socketio` is listed in `pyproject.toml` (already a dep) but no SocketIO integration exists - No branch matching `mesh-seed-236` exists; no commits reference this issue in any branch. ### Conclusion - This issue remains **open** on Forgejo because the work was never attempted successfully. - The "done" status on the kanban fixit board is a reconciliation artifact, not a delivery signal. - A new fixit task has been filed on the kanban fixit board to re-attempt the implementation. ### Acceptance criteria remaining (all unchecked) - [ ] WebSocket connection established from browser to mesh backend - [ ] Messages sent from browser are received by the backend and routed as mesh intents - [ ] Response intents are streamed back to the browser in real-time - [ ] Existing REST API endpoints remain unaffected - [ ] Static frontend files served correctly via Flask - [ ] SocketIO event handlers tested: connect, disconnect, message, error - [ ] Graceful reconnection handling on disconnect QA verification complete. The new fixit card will track the actual implementation.
Author
Owner

QA Verification — FAIL — second false-positive closure

The reconciliation sweep at 04:34Z closed this issue, then it was reopened at 04:46Z, then closed again at 08:03Z. Neither close was backed by a real fix on master. Independent re-verification as of 04:58Z:

Repository state (master HEAD 92521ce)

  • runtime/ws_handler.py — does not exist on master (404 via API)
  • runtime/static/ — does not exist on master
  • tests/unit/test_ws_handler.py — does not exist on master
  • runtime/http_entrypoint.py last touched 2026-04-23 by commit 9d69544 (fix #137, unrelated)
  • No branch mesh-seed-236, no commits referencing this issue
  • Files in worktree /home/b/Projects/mesh-seed exist locally as untracked modifications left over from earlier attempts (timestamps 01:19-01:23 Aug 4)

Unit tests (in worktree, against untracked files)

  • 14/17 pass (handler logic, socketio init, event emission)
  • 3/17 FAIL: test_static_css_served, test_static_js_served, test_static_missing_file_returns_404 — Flask's default static endpoint is still registered because register_static_routes only sets static_folder=None after Flask eagerly registers the route on construction, leaving the default send_static_file handler reachable.

Fixit board state

  • t_3f6b4d24 (original, done) — janitor auto-escalated after 178h blocked; no code landed
  • t_c3f55b4d (re-attempt) — dispatched 07:53, blocked 07:53 with no-changes: agent exited 0 but no commit/PR on worktree /home/b/Projects/mesh-seed. The agent found the untracked files already there and concluded no work was needed.

Conclusion

This is a second false-positive closure. No fix has been landed on master. The implementation work exists in the local worktree but is uncommitted and partially broken (static-serving tests fail). Reopened at 04:58Z and routed back to the fixit pipeline for a real implementation attempt.

## QA Verification — FAIL — second false-positive closure The reconciliation sweep at 04:34Z closed this issue, then it was reopened at 04:46Z, then closed again at 08:03Z. Neither close was backed by a real fix on master. Independent re-verification as of 04:58Z: ### Repository state (master HEAD 92521ce) - `runtime/ws_handler.py` — **does not exist** on master (404 via API) - `runtime/static/` — **does not exist** on master - `tests/unit/test_ws_handler.py` — **does not exist** on master - `runtime/http_entrypoint.py` last touched 2026-04-23 by commit `9d69544` (fix #137, unrelated) - No branch `mesh-seed-236`, no commits referencing this issue - Files in worktree `/home/b/Projects/mesh-seed` exist locally as **untracked** modifications left over from earlier attempts (timestamps 01:19-01:23 Aug 4) ### Unit tests (in worktree, against untracked files) - 14/17 pass (handler logic, socketio init, event emission) - 3/17 FAIL: `test_static_css_served`, `test_static_js_served`, `test_static_missing_file_returns_404` — Flask's default `static` endpoint is still registered because `register_static_routes` only sets `static_folder=None` after Flask eagerly registers the route on construction, leaving the default `send_static_file` handler reachable. ### Fixit board state - `t_3f6b4d24` (original, done) — janitor auto-escalated after 178h blocked; no code landed - `t_c3f55b4d` (re-attempt) — dispatched 07:53, blocked 07:53 with `no-changes: agent exited 0 but no commit/PR on worktree /home/b/Projects/mesh-seed`. The agent found the untracked files already there and concluded no work was needed. ### Conclusion This is a second false-positive closure. No fix has been landed on master. The implementation work exists in the local worktree but is uncommitted and partially broken (static-serving tests fail). Reopened at 04:58Z and routed back to the fixit pipeline for a real implementation attempt.
Mark closed this issue 2026-08-04 12:05:50 +00:00
Mark reopened this issue 2026-08-04 13:45:08 +00:00
Author
Owner

QA Verification — FAIL — third false-positive closure

The 12:05:50Z closure of this issue was a third false-positive, repeating the pattern flagged at 04:46Z and 12:02Z. Reopened.

Repository state (master HEAD 92521ce956)

  • runtime/ws_handler.py — does not exist on master (404 via API)
  • runtime/static/ — does not exist on master
  • tests/unit/test_ws_handler.py — does not exist on master
  • runtime/http_entrypoint.py last touched 2026-04-23 (commit 9d69544, fix #137, unrelated)
  • No branch mesh-seed-236, no commits referencing this issue on any branch
  • Worktree /home/b/Projects/mesh-seed has the implementation as untracked files left over from earlier attempts (timestamps 01:19-01:23 Aug 4) — same state as the 12:02Z QA noted

Unit tests in worktree (.venv/bin/pytest tests/unit/test_ws_handler.py)

  • 14/17 pass (handler logic, socketio init, event emission)
  • 3/17 FAIL — same three static-serving tests that failed at the 12:02Z QA:
    • test_static_css_served
    • test_static_js_served
    • test_static_missing_file_returns_404
  • Failure cause: RuntimeError: 'static_folder' must be set to serve static_files. raised in Flask's default send_static_file handler. register_static_routes sets static_folder=None after Flask eagerly registers the default /static route during app construction, so the route remains reachable.

Close history (timeline, in order)

  • 04:34:54Z close (reconciliation sweep) — phantom, reopened at 04:46:33Z
  • 08:03:09Z close (second reconciliation sweep) — phantom, reopened at 12:01:55Z
  • 12:05:50Z close (third) — phantom, reopened at this QA

No commit has landed the implementation on master. The previous QA FAIL identified the same root cause (static_folder is not unset before Flask's constructor registers the default static route); the 14/17 partial implementation has been sitting untracked in the worktree since 01:19 Aug 4 and no follow-up fixit attempt has landed.

Conclusion

This issue remains genuinely open. The implementation is incomplete (static-serving tests fail) and uncommitted (worktree-only untracked files). Needs a real fixit attempt that (a) commits the partial implementation, (b) fixes the static-folder registration order, and (c) lands it on master via PR.

Reopened for the fixit pipeline.

## QA Verification — FAIL — third false-positive closure The 12:05:50Z closure of this issue was a third false-positive, repeating the pattern flagged at 04:46Z and 12:02Z. Reopened. ### Repository state (master HEAD 92521ce956cf0fc9fb19c4dc9f286f3fe87f70c1) - `runtime/ws_handler.py` — **does not exist** on master (404 via API) - `runtime/static/` — **does not exist** on master - `tests/unit/test_ws_handler.py` — **does not exist** on master - `runtime/http_entrypoint.py` last touched 2026-04-23 (commit 9d69544, fix #137, unrelated) - No branch `mesh-seed-236`, no commits referencing this issue on any branch - Worktree `/home/b/Projects/mesh-seed` has the implementation as **untracked** files left over from earlier attempts (timestamps 01:19-01:23 Aug 4) — same state as the 12:02Z QA noted ### Unit tests in worktree (.venv/bin/pytest tests/unit/test_ws_handler.py) - 14/17 pass (handler logic, socketio init, event emission) - 3/17 FAIL — same three static-serving tests that failed at the 12:02Z QA: - `test_static_css_served` - `test_static_js_served` - `test_static_missing_file_returns_404` - Failure cause: `RuntimeError: 'static_folder' must be set to serve static_files.` raised in Flask's default `send_static_file` handler. `register_static_routes` sets `static_folder=None` after Flask eagerly registers the default `/static` route during app construction, so the route remains reachable. ### Close history (timeline, in order) - 04:34:54Z close (reconciliation sweep) — phantom, reopened at 04:46:33Z - 08:03:09Z close (second reconciliation sweep) — phantom, reopened at 12:01:55Z - 12:05:50Z close (third) — phantom, reopened at this QA No commit has landed the implementation on master. The previous QA FAIL identified the same root cause (`static_folder` is not unset before Flask's constructor registers the default static route); the 14/17 partial implementation has been sitting untracked in the worktree since 01:19 Aug 4 and no follow-up fixit attempt has landed. ### Conclusion This issue remains **genuinely open**. The implementation is **incomplete** (static-serving tests fail) and **uncommitted** (worktree-only untracked files). Needs a real fixit attempt that (a) commits the partial implementation, (b) fixes the static-folder registration order, and (c) lands it on master via PR. Reopened for the fixit pipeline.
Author
Owner

QA Verification — FAIL — fourth false-positive closure

The issue was closed at 2026-08-04T13:46:06Z (presumably by another automated sweep) after being reopened at 13:45:17Z with a QA FAIL comment (#50118). The fix has not been implemented.

Repository state (master HEAD 92521ce956)

  • runtime/ws_handler.py — does not exist on master (404 via API)
  • runtime/static/ — does not exist on master
  • tests/unit/test_ws_handler.py — does not exist on master
  • runtime/http_entrypoint.py — no Flask-SocketIO import (no socketio or SocketIO in source; standard Flask only)

Pattern

This issue has now been falsely closed four times by automated sweeps without any code change landing on master. The fixit card t_3f6b4d24 was blocked at kilo-gsd preflight (run 370, 2026-04-23) and never unblocked. The janitor then auto-escalated it to done, which triggered reconciliation closures that were not backed by real fixes.

Required

Real implementation of Phase 1 (WebSocket backend + static file serving) per the acceptance criteria in the issue body. This requires actual code changes, not automated reconciliation.

## QA Verification — FAIL — fourth false-positive closure The issue was closed at 2026-08-04T13:46:06Z (presumably by another automated sweep) after being reopened at 13:45:17Z with a QA FAIL comment (#50118). The fix has **not** been implemented. ### Repository state (master HEAD 92521ce956cf0fc9fb19c4dc9f286f3fe87f70c1) - `runtime/ws_handler.py` — **does not exist** on master (404 via API) - `runtime/static/` — **does not exist** on master - `tests/unit/test_ws_handler.py` — **does not exist** on master - `runtime/http_entrypoint.py` — **no Flask-SocketIO import** (no `socketio` or `SocketIO` in source; standard Flask only) ### Pattern This issue has now been falsely closed four times by automated sweeps without any code change landing on master. The fixit card `t_3f6b4d24` was blocked at kilo-gsd preflight (run 370, 2026-04-23) and never unblocked. The janitor then auto-escalated it to `done`, which triggered reconciliation closures that were not backed by real fixes. ### Required Real implementation of Phase 1 (WebSocket backend + static file serving) per the acceptance criteria in the issue body. This requires actual code changes, not automated reconciliation.
Author
Owner

Re-opened: false-positive close confirmed. Issue was closed but no fix commit exists on master. Re-adding triage-approved to route back through the pipeline.

Re-opened: false-positive close confirmed. Issue was closed but no fix commit exists on master. Re-adding triage-approved to route back through the pipeline.
Mark closed this issue 2026-08-08 08:57:51 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Mark/mesh-seed#236
No description provided.