ci(chat): pkgs/chat go tests (5 tests pinning broadcast + registry concurrency) run by no workflow — go-modules-build.yml builds and vets but never tests

Problem

pkgs/chat/main_test.go — the only test suite for the pkgs/chat TUI chat program — is run by no workflow. The one workflow that touches the module, go-modules-build.yml, verifies tidy/build/vet only; it never runs go test. pkgs/chat is also the only module in that workflow's matrix that has any tests at all, so the gap is invisible: the workflow is green whether the tests pass, fail, or are deleted.

Evidence (verified this run, laptop primary @ `e90672d`, HEAD == origin/main)

.github/workflows/go-modules-build.yml (matrix line ~57: module: [chat, database, graph, import, launcher, tea]) runs exactly three verifications per module: go mod tidy cleanliness, go build ./..., and go vet ./.... There is no go test step in the file, and no other workflow mentions pkgs/chat.
Hand run on the laptop this run: cd pkgs/chat && go test ./... → ok, 5 tests pass (1.128 s, fully offline).
What the 5 tests pin (main_test.go lines 68–207, against the 238-line main.go): Enter on empty input broadcasts nothing; Enter on real text broadcasts it verbatim exactly once; send reaches only live programs (removed sessions get nothing); removing an unknown session is a no-op; and the registry holds up under concurrent register/send/remove.
Why these pins matter here: the open chat issues are exactly in this area — chat: broadcast fan-out runs each Send in its own goroutine — messages arrive out of order and a stalled session piles up unbounded blocked goroutines #4389 (broadcast fan-out ordering / unbounded blocked goroutines), chat: completion waiter can block forever on p.Wait() before program startup — session never deregistered #4515 (completion waiter can block forever; session never deregistered), chat: per-session message history is never trimmed — every message re-joins the full history into the 5-line viewport, so a long-lived session grows unbounded and rendering is quadratic #3268 (unbounded per-session history). The registry/broadcast contract tests are the regression net for those fixes, and today a fix for any of them can merge with the net never run.

Why it matters

Build+vet proves the chat program compiles; it says nothing about the broadcast semantics that are its whole behaviour. The suite exists, is fast and offline, and covers the precise subsystem with three open concurrency/lifecycle bugs — it is simply never executed.

Acceptance criteria

An automated check (a go test ./... step in go-modules-build.yml for the chat matrix entry, or an equivalent workflow) runs the pkgs/chat tests on changes under pkgs/chat/.
The check passes on current main (5 tests at filing).
Breaking a pinned behaviour (e.g. broadcasting empty input, or delivering to a removed session) makes the check fail.

CODE-1756

🤖 Agent note · state: filed

Agent: new-issue-creator (new-issue-creator-code-b)
Session / ID: cron job new-issue-creator-code-b, run 2026-11-05 00:20 CST
Found via: filed this run
Task: Filed this issue — pkgs/chat's Go test suite (main_test.go: broadcast + registry-concurrency contract) is run by no workflow; go-modules-build.yml covers the module with tidy/build/vet only and has no go test step. Verified by reading the workflow, plus a hand run on the laptop @e90672dc9e (go test ./... ok, 5 tests pass).
Expectation: effort xs — add a go test step for the chat matrix entry (or equivalent); done when it passes on current main and broadcasting empty input fails it.
Links: packet hidden_files/packet-6099-triage.json (queue repo-health-code-pilot)

🤖 Agent note · picked up

Agent: repo-worker-code (OpenChamber scheduled lane)
Session / ID: ses_e5e55a2bd80ffeS1HxLDGj2qhQ; queue task 9910
Found via: repo-health-code-pilot, lane 9aca43b4-5439-4939-9f71-323f5d32521b
Task: Revalidate ci(chat): pkgs/chat go tests (5 tests pinning broadcast + registry concurrency) run by no workflow — go-modules-build.yml builds and vets but never tests #6099, its go-modules workflow coverage, and any existing PR before triage.
Expectation: Record a verified triage disposition and an implementation follow-up if the CI gap remains.
Links: ci(chat): pkgs/chat go tests (5 tests pinning broadcast + registry concurrency) run by no workflow — go-modules-build.yml builds and vets but never tests #6099

🤖 Agent note · triage findings

Agent: repo-worker-code (OpenChamber scheduled lane)
Session / ID: ses_e5e55a2bd80ffeS1HxLDGj2qhQ; queue task 9910
Finding: ci(chat): pkgs/chat go tests (5 tests pinning broadcast + registry concurrency) run by no workflow — go-modules-build.yml builds and vets but never tests #6099 remains open. The main workflow includes chat in its Go module matrix and runs build/vet, but it does not run go test; workflow code search found no go test step. The only PR from the broad issue-number search is unrelated aggregator work (feat(aggregator): report quota extractor health (#1204) #3957).
Disposition: Confirmed and actionable. The focused pkgs/chat test suite has a reported 5-test passing baseline; this is a small CI wiring fix with no behavior changes.
Evidence: ci(chat): pkgs/chat go tests (5 tests pinning broadcast + registry concurrency) run by no workflow — go-modules-build.yml builds and vets but never tests #6099

🤖 Agent note · handed off

Agent: repo-worker-code (OpenChamber scheduled lane)
Session / ID: ses_e5e55a2bd80ffeS1HxLDGj2qhQ; completed queue task 9910
Task: Triage confirmed that the existing pkgs/chat Go tests are not run by the module workflow.
Handoff: Follow-up small-fix task 9911 is queued in repo-health-code-pilot to add a guarded go test check. Related open PRs fix(chat): preserve broadcast order with bounded recipient queues #4530, fix(chat): treat server shutdown as clean stop #4328, and fix(chat): deregister sessions on session end instead of p.Wait() (#4515) #4521 touch pkgs/chat source/tests only, not workflows, so they do not own the CI wiring.
Links: ci(chat): pkgs/chat go tests (5 tests pinning broadcast + registry concurrency) run by no workflow — go-modules-build.yml builds and vets but never tests #6099

🤖 Agent note · handed off

Agent: queue worker (repo-worker-code), lane code-v
Session / ID: task 9911
Found via: queue claim
Task: Handed off task 9911 (issue ci(chat): pkgs/chat go tests (5 tests pinning broadcast + registry concurrency) run by no workflow — go-modules-build.yml builds and vets but never tests #6099: run pkgs/chat Go tests in CI) to the opencode execution lane — the laptop claimant launches the bound opencode session that drives task 9911 to its terminal state. Fresh check: issue ci(chat): pkgs/chat go tests (5 tests pinning broadcast + registry concurrency) run by no workflow — go-modules-build.yml builds and vets but never tests #6099 is OPEN, no hard-stop labels, claim labels already in sync.
Expectation: effort/s; done = a guarded go test ./... check for pkgs/chat in CI (fails if pkgs/chat/main_test.go is absent), passing on current main.
Links: issue ci(chat): pkgs/chat go tests (5 tests pinning broadcast + registry concurrency) run by no workflow — go-modules-build.yml builds and vets but never tests #6099

Navigation Menu

Repository navigation

ci(chat): pkgs/chat go tests (5 tests pinning broadcast + registry concurrency) run by no workflow — go-modules-build.yml builds and vets but never tests #6099

Problem

Evidence (verified this run, laptop primary @ `e90672d`, HEAD == origin/main)

Why it matters

Acceptance criteria

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

ci(chat): pkgs/chat go tests (5 tests pinning broadcast + registry concurrency) run by no workflow — go-modules-build.yml builds and vets but never tests #6099

Description

Problem

Evidence (verified this run, laptop primary @ e90672d, HEAD == origin/main)

Why it matters

Acceptance criteria

Activity

developing-today commented on Nov 5, 2026

dezren39 commented on Nov 5, 2026

dezren39 commented on Nov 5, 2026

dezren39 commented on Nov 5, 2026

dezren39 commented on Nov 5, 2026

dezren39 commented on Nov 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Evidence (verified this run, laptop primary @ `e90672d`, HEAD == origin/main)