fix(group): atomic/reconciled group create — no permanent orphan rows (#394)

[lml2468]

Summary

Fixes #394. group.CreateGroup created the IM channel after tx.Commit(); on IM-create failure it ran a best-effort, non-atomic compensating DELETE that only logged. A DB blip on that delete — or a crash between commit and IM-create — left an orphan group with no backing IM channel, permanently queryable.

• channel_synced flag (migration, DEFAULT 1 for backward compat). CreateGroup writes new rows as 0 in-tx and flips to 1 only after a confirmed IM channel create. Existing rows / other insert paths keep the DB default 1, so they're never mis-detected as orphans.
• Compensating delete kept (narrows the window) but orphans are now detectable via channel_synced=0 instead of silently permanent.
• Idempotent periodic reconcile worker: finds channel_synced=0 rows older than a grace window, re-creates the IM channel (IMCreateOrUpdateChannel is create-or-update → idempotent) and flips the flag. Optional Redis tick-lock dedups across instances; lock-free fallback stays correct via idempotency. Disabled under cfg.Test; interval/grace tunable via DM_GROUP_CHANNEL_RECONCILE_INTERVAL_SEC / _GRACE_SEC.
• Observability: Prometheus metrics for channel-create result, reconcile ticks, orphans detected, and per-orphan outcome.
• IM-create call injected on Service so failure modes are unit-testable.

Acceptance (#394)

• ✅ A group can never remain queryable without a backing IM channel after a create failure — orphans are now reconciled (eventual consistency), not permanent.
• ✅ Reconcile is observable (metrics + structured logs) and idempotent.

API contract

No REST/WS contract change. channel_synced is internal; the group-create response shape is unchanged.

Test plan

• TestCreateGroup_Success_MarksChannelSynced — happy path flips flag to 1
• TestCreateGroup_IMFail_CompensatingDeleteRemovesGroup — IM-fail + delete-OK leaves no orphan
• TestChannelReconcile_RecreatesChannelAndFlipsFlag — crash-between-commit-and-IM / delete-fail residue recovered
• TestChannelReconcile_Idempotent — second run is a no-op
• TestChannelReconcile_RespectsGraceWindow — in-flight creates not raced
• TestChannelReconcile_SkipsDisbandedGroup — disbanded channels not recreated
• TestChannelReconcile_IMFailLeavesOrphanForRetry — flag stays 0 for retry on IM failure
• full go test ./modules/group/ green; go build ./... green

🤖 OCT-16 (sub-task of OCT-10)

[mochashanyao]

[Octo-Q · automated review]

Verdict: Approve — no blocking findings; notes below (data-flow traced).

---

octo-server PR#410 Review Report — automated review

Reviewer: Octo-Q (automated review)
PR: #410
Head SHA: de9f843c83256ae41be23b8fe6474e4452fd391e
Title: fix(group): atomic/reconciled group create — no permanent orphan rows (#394)
Changed files: 7 (+736 / -8)

---

1. Verification Summary

Item	Status	Evidence
channel_synced column migration (idempotent, DEFAULT 1)	✅	sql/20260617000001_group_channel_synced.sql — INFORMATION_SCHEMA guard + stored proc, matches project pattern (#239/#253)
Model struct NOT carrying channel_synced	✅	db.go:622-649 — no ChannelSynced field; AttrToUnderscore won't leak it into other Insert paths
Other Insert paths keep DB default 1	✅	event.go:173 (system group), event.go:315 (registered group), service.go:194 (AddGroup) — all use InsertTx/Insert with Model struct, no markChannelPendingTx call
markChannelPendingTx inside tx before commit	✅	service.go:1148-1152 — called after InsertTx, before tx.Commit() at line 1261
MarkChannelSynced after IM create success	✅	service.go:1316-1319 — after imCreateChannel returns nil
Compensating delete preserved on IM fail	✅	service.go:1299-1312 — delete group_member then group, same as before
Reconciler queries only GroupStatusNormal	✅	db.go:78-85 — WHERE channel_synced=0 AND status=? with GroupStatusNormal; disbanded/disabled excluded
Grace window prevents racing in-flight creates	✅	db.go:82 — created_at < DATE_SUB(NOW(), INTERVAL ? SECOND)
IM create is idempotent (IMCreateOrUpdateChannel)	✅	config.Context interface — create-or-update semantics, safe for reconcile replay
GetSubscribableMemberUIDs excludes blacklist/deleted	✅	db.go:530-537 — is_deleted=0 AND status=GroupMemberStatusNormal
Redis lock: SET NX EX + Lua CAS-DEL	✅	channel_reconcile.go:82-86 (Acquire), channel_reconcile.go:72-77 (Lua release script)
Lock failure degrades to lock-free (idempotent)	✅	channel_reconcile.go:196-199 — logs warning, continues
Test coverage	✅	7 tests covering happy path, IM fail + compensating delete, reconcile recovery, idempotency, grace window, disbanded skip, IM retry
Test mode disables worker	✅	api.go:89 — if g.ctx.GetConfig().Test { return }

2. Findings

P2-1: QueryReconcilableGroupNos uses fmt.Sprintf for SQL interpolation

File: db.go:82
Diff-scope: new (introduced by this PR)

Where(fmt.Sprintf("created_at < DATE_SUB(NOW(), INTERVAL %d SECOND)", graceSeconds))

graceSeconds is int so %d is safe from SQL injection today. However, this pattern is fragile — a future refactor changing the parameter type to string would silently introduce a SQL injection. The project's other queries consistently use ? parameterization.

Recommendation: Use dbr.Expr("created_at < DATE_SUB(NOW(), INTERVAL ? SECOND)", graceSeconds) or a raw Where("created_at < DATE_SUB(NOW(), INTERVAL ? SECOND)", graceSeconds) to keep it parameterized.

P2-2: Redis lock client never closed

File: channel_reconcile.go:93-99, api.go:119
Diff-scope: new (introduced by this PR)

newRedisReconcileLock creates a dedicated rd.Client via rd.NewClient(...), but:

• ChannelReconciler stores only the reconcileTickLock interface, not the concrete *redisReconcileLock.
• redisReconcileLock.Close() exists but is never called.
• Group struct stores reconciler *ChannelReconciler but has no shutdown hook to close the lock's Redis connection pool.

On process exit the OS reclaims sockets, so this is not a production correctness issue. But it leaks FDs in long-running integration tests or if the module is ever hot-reloaded.

Recommendation: Either (a) have ChannelReconciler store the concrete lock and expose a Close() that calls lock.Close(), invoked from a module shutdown hook, or (b) reuse the existing shared Redis client from octoredis instead of creating a dedicated one.

Nit-1: No retry cap for permanently-failing orphans

File: channel_reconcile.go:228-267
Diff-scope: new

If the IM service is permanently unavailable for a specific group, the reconciler retries every 2 minutes indefinitely. This generates continuous im_fail metrics and log noise. Consider adding a retry_count column or a last_attempt_at timestamp to implement exponential backoff or a max-retry cutoff with alerting.

Nit-2: Partial compensating delete edge case

File: service.go:1303-1312
Diff-scope: pre-existing (amplified visibility)

If IM creation fails → compensating delete of group_member succeeds → compensating delete of group fails, the group row remains with channel_synced=0 and zero members. The reconciler will then:

1. Call GetSubscribableMemberUIDs → returns empty
2. Mark channel_synced=1 (skip)

Result: a queryable group with zero members and an unnecessary IM channel. This is a pre-existing edge case (old code left the same orphan permanently), and the PR's behavior is arguably better (at least the channel exists), but worth noting.

3. Recommendations

1. Parameterize the grace-seconds SQL (P2-1) — low-effort, high-value defensive coding.
2. Wire up Redis lock cleanup (P2-2) — either close on shutdown or reuse the shared client.
3. Consider a retry cap / backoff for the reconciler (Nit-1) as a follow-up.

4. Additional Observations

• The event.go system-group and registered-group creation paths create the IM channel before tx.Commit() and rollback on failure — they have no orphan window and correctly don't need channel_synced treatment. The PR's scope (only CreateGroup in service.go) is correct.
• The integration/api_groups.go path calls groupService.CreateGroup() and thus inherits the fix automatically.
• The migration's DEFAULT 1 design is well-thought-out: existing rows and non-CreateGroup insert paths all get channel_synced=1 without any data migration.

5. Data-Flow Trace

Consumed Data	Upstream Source	Flows Correctly?
channel_synced=0 in reconcile query	markChannelPendingTx → tx.Update SET channel_synced=0 inside CreateGroup tx, before commit	✅ — committed atomically with group row
channel_synced=1 flip	MarkChannelSynced → session.Update SET channel_synced=1 after IM create success	✅ — failure is non-blocking, reconcile retries
Subscribers in reconcile IM create	GetSubscribableMemberUIDs → querySubscribableMemberUIDsWithGroupNo (is_deleted=0 AND status=Normal)	✅ — excludes blacklist/deleted, same source as 1module.go Subscribers callback
groupNos in reconcile scan	QueryReconcilableGroupNos → SELECT group_no FROM group WHERE channel_synced=0 AND status=1 AND created_at < grace	✅ — correctly filters by status and grace window
imCreateChannel injection	Service.imCreateChannel field, default = ctx.IMCreateOrUpdateChannel in NewService	✅ — tests inject mock, production uses real IM call
DB default channel_synced=1 for non-CreateGroup paths	Migration DEFAULT 1 + Model struct has no ChannelSynced field → AttrToUnderscore omits it	✅ — verified event.go:173, event.go:315, service.go:194 all use Model-based Insert

6. R5 Blind-Spot Checklist (security_sensitive)

• C1 — Dual-path parity: N/A. This PR adds a create-side safety flag; there is no symmetric "un-create" path. The compensating delete is best-effort and unchanged in structure. The reconcile worker only creates (never deletes) channels — asymmetric by design.
• C2 — Control-flow ordering / nesting reuse: Clear. markChannelPendingTx runs inside the tx before commit (correct ordering). MarkChannelSynced runs after IM success (correct). The Lua CAS-DEL lock release is the standard safe pattern. The fmt.Sprintf SQL interpolation uses %d with an int — safe for current code but fragile (see P2-1).
• C3 — Authorization boundary ≠ capability boundary: N/A. The reconciler is a system-internal background worker with no user-facing endpoint. It operates on DB rows, not user requests. No new API surface is exposed.
• C4 — Authorization lifecycle / container-member cascade: N/A. This PR does not touch authorization or access control. The channel_synced flag is an internal operational flag, not an authorization gate.

7. Cross-Round Blocker Recheck

N/A — first review of this PR.

---

[Octo-Q] verdict: APPROVE

No P0/P1 findings. The PR correctly addresses the orphan-group problem with a well-designed two-layer defense (in-tx pending flag + idempotent reconcile worker). Data-flow tracing confirms all consumed data reaches its consumption point correctly. The two P2 findings (SQL interpolation style, Redis client leak) are maintainability improvements that don't block landing.

[yujiawei]

Code Review — PR #410 (octo-server)

Scope reviewed: head de9f843c83256ae41be23b8fe6474e4452fd391e against base main (merge-base fe8da596). 7 files, +736/-8. go build ./... green; the PR's new tests (TestChannelReconcile_*, TestCreateGroup_Success_MarksChannelSynced, TestCreateGroup_IMFail_CompensatingDeleteRemovesGroup) pass in isolation. (The full modules/group package hits a pre-existing Error 1040: Too many connections at test-server setup in an unrelated test — an environment connection-cap issue, not introduced by this PR.)

This was reviewed with extra care as a security-sensitive change. The new Redis tick-lock is the only security-relevant surface and it is implemented correctly (SET NX EX acquire + token-aware Lua CAS-DEL release), matching the established pattern in modules/oidc.

Verdict: APPROVED

The change is sound and strictly improves on the status quo: a create-time IM failure used to leave a permanently orphaned, queryable group; it now leaves a detectable, self-healing one (channel_synced=0 → reconcile). The migration is backward-compatible (DEFAULT 1, guarded/idempotent procedure pattern), the insert/flag are correctly transactional, and the design (forward-recovery via an idempotent create-or-update) is internally consistent and well-tested.

No P0/P1 blocker was confirmed. The findings below are P2 hardening items and one design decision that merits explicit human product sign-off (this PR carries needs-human-review).

---

Findings

① Reconcile vs. teardown race — reconciler can recreate a channel for a group being torn down (P2)

modules/group/channel_reconcile.go:236-267

QueryReconcilableGroupNos filters status = GroupStatusNormal, so disbanded groups are normally excluded. But within a single tick there is a TOCTOU window: a candidate selected at scan time can be disbanded (or its rollback delete can land) between selection and the imCreateChannel call, after which the worker recreates the IM channel from a stale member snapshot and treats the subsequent zero-row MarkChannelSynced as success.

• Impact: a stray IM channel for a group that should no longer have one. No data loss, bounded to one tick's per-item window, and the precondition is an already-rare orphan.
• Suggested hardening: re-read status/channel_synced (ideally a conditional UPDATE ... WHERE channel_synced=0 AND status=Normal) immediately before recreating, and act on RowsAffected from MarkChannelSynced instead of discarding it.

② Compensating-delete vs. concurrent recovery — unconditional delete can orphan a just-recovered channel (P2)

modules/group/service.go:1291-1315

If the CreateGroup IM-create call blocks past the grace window (≥120s) and then returns an error, another instance's reconciler may have already recreated the channel and flipped channel_synced=1. The failure branch then deletes the rows unconditionally, leaving the recovered IM channel orphaned and returning a false "create failed."

• Impact: reverse-orphan (channel without group) plus a misleading error, only under extreme IM latency (>grace). Narrow and degradation-only.
• Suggested hardening: make the compensating delete conditional (DELETE ... WHERE channel_synced=0), so it no-ops once a row has been recovered.

③ Worker lifecycle is never shut down (P2)

modules/group/api.go:90-122, modules/group/channel_reconcile.go:188-193

startChannelReconciler() launches a ticker goroutine with context.Background() and constructs a dedicated Redis client, but the group module registers no Stop in its register.Module (modules/group/1module.go), so neither ChannelReconciler.Stop() nor redisReconcileLock.Close() is ever called on graceful shutdown / module reload.

Note: the in-code rationale ("main.go only calls module.Setup, not module.Start") is inaccurate — server.Start() does call module.Start(ctx), and the cited modules/oidc precedent it follows registers Start: o.Init, Stop: o.Close and cleans up both its worker goroutine and its Redis client in Close(). Tests are unaffected (the cfg.Test guard early-returns, so no goroutine/connection leak in the suite); the leak is production-shutdown-only (process is exiting anyway), hence P2 rather than a blocker.

• Suggested fix: mirror the oidc precedent — register Stop on the group module, have it call reconciler.Stop() and close the lock's Redis client.

④ Start() mutates cancel/wg without a mutex (P2, defensive)

modules/group/channel_reconcile.go:220-246

Start() documents itself as safe to call repeatedly but mutates r.cancel/r.wg unsynchronized. In the current wiring it is only ever called once, so this is latent — worth a mutex if it ever becomes re-callable from multiple goroutines.

---

Design decision to confirm (human sign-off)

The reconciler implements forward-recovery: a group whose creation returned an error to the caller (commit succeeded, IM-create + compensating-delete both failed) is later completed into a fully working group by the worker, rather than cleaned up. This is deliberate and documented, and it satisfies the stated acceptance criteria of the linked issue. The alternative — cleanup-forward (delete the orphan, honoring the failure the user already saw) — is also defensible. Because this is the central product trade-off of the change and the PR is flagged for human review, the owner should explicitly confirm "resurrect" over "clean up" is the intended semantics.

---

Notes on the review process

Three independent review passes were run and reconciled. One cross-pass finding ("the group insert commits outside the transaction with the default channel_synced=1") was rejected on verification: service.go:1129 uses s.db.InsertTx(&Model{...}, tx), and markChannelPendingTx runs in the same tx, so insert + flag commit atomically — there is no non-transactional pre-commit window. A second pass framed findings ①/② as P0 data-corruption; on evidence review they are narrow, bounded, non-data-loss edge cases that improve on the baseline (which had permanent orphans), so they are recorded here as P2.

Coverage / not assessed from the diff

• Runtime idempotency of ctx.IMCreateOrUpdateChannel is taken on the PR's word (create-or-update) — not verified against the WuKongIM-side implementation here.
• Production behavior of the Redis tick-lock under real multi-instance contention and Redis failover was reasoned about, not exercised.
• Metric cardinality is fine (fixed label sets, no per-group labels); /metrics exposure wiring is out of this diff.

[yujiawei]

Heads-up on the red Test check (non-blocking, not a logic failure): the failure is Error 1040: Too many connections in the modules/group package (TestGroupInviteDetail_IncludesSpaceName_Anonymous this run; the exact victim test varies run-to-run). Root cause is the shared test harness — testutil.NewTestServer() opens a fresh MySQL pool per call and never closes it, so the package's now-233 test functions (this PR adds 7) can exceed the CI MySQL max_connections. The new tests here pass cleanly in isolation, and main is green. Likely needs either a small bump to CI max_connections headroom or a harness fix to close pools in teardown — flagging so the 1040 isn't mistaken for a defect in this change.

[yujiawei]

One additional non-blocking note (does not change the approval): QueryReconcilableGroupNos (modules/group/db.go:75) builds the grace-window predicate with fmt.Sprintf("created_at < DATE_SUB(NOW(), INTERVAL %d SECOND)", graceSeconds) rather than ? parameterization. It's safe today because graceSeconds is typed int, but it diverges from the parameterized style used elsewhere in this file and would silently become injectable if the parameter type ever changed. Suggest Where("created_at < DATE_SUB(NOW(), INTERVAL ? SECOND)", graceSeconds) to keep it consistent and future-proof.

[lml2468]

QA Review - FAIL

Verdict: FAIL
AC source: linked issue #394
CI status: failing (Test, check-sprint / check-sprint)
Test diff: +1 file, ~195 lines (modules/group/channel_reconcile_test.go)

One-line conclusion

The PR has meaningful AC-focused tests and appears to cover the core recovery design, but QA cannot pass it while PR CI is red: the Test job failed with Error 1040: Too many connections, and check-sprint failed because issue #394 has no Sprint set.

AC coverage matrix

AC #	Description	Code path	Test	Assertion strength	Status
AC1	A group must not remain permanently queryable without a backing IM channel after create failure; eventual reconciliation is acceptable.	modules/group/service.go:1146 marks channel_synced=0 in the create tx; modules/group/channel_reconcile.go:208 scans and :251 recreates the IM channel; modules/group/service.go:1293 flips to synced after create success.	TestCreateGroup_Success_MarksChannelSynced, TestCreateGroup_IMFail_CompensatingDeleteRemovesGroup, TestChannelReconcile_RecreatesChannelAndFlipsFlag, TestChannelReconcile_IMFailLeavesOrphanForRetry	Strong for state/flag/retry behavior	OK, but CI failed
AC2	Reconcile is observable and idempotent.	modules/group/metrics.go:50 adds create/reconcile counters; modules/group/channel_reconcile.go:213 and :266 record tick/outcome; structured logs include groupNo/count.	TestChannelReconcile_Idempotent; no direct metric/log assertion.	Medium	PARTIAL/RISK
AC3	Verify both failure modes: IM-fail + delete-fail residue and crash-between-commit-and-IM residue.	Both cases converge to channel_synced=0 rows processed by QueryReconcilableGroupNos and reconcileOne.	TestChannelReconcile_RecreatesChannelAndFlipsFlag seeds the orphan residue and verifies channel recreate + flag flip.	Medium-strong for residue recovery, not full delete-fail injection	OK/RISK

Boundary / edge cases

Path	Boundary category	Tested
CreateGroup success	post-commit IM create succeeds, flag flips to 1	Yes
CreateGroup IM failure	compensating delete succeeds, no orphan remains	Yes
Reconcile stale orphan	recreates IM channel and flips flag	Yes
Reconcile retry	IM recreate fails, flag remains 0 for retry	Yes
Reconcile grace window	fresh pending groups are not raced	Yes
Disbanded group	not recreated	Yes
Concurrent disband/delete after scan	stale candidate can be recreated before final mark	No; code-review already noted as P2 risk
Zero-member normal orphan	marks synced without IM channel	Not directly tested; product semantics should confirm this is acceptable

Regression risk

• Touched module: shared modules/group create/reconcile path plus an internal DB migration.
• Recent churn: 12 commits in the changed group files over the last 30 days.
• Public contract: no REST/WS response-shape change claimed; internal schema changes via channel_synced.
• Risk rating: High, because this touches shared group creation and a background worker, even though the code improves the orphan baseline.

Observability

• Structured logs for lock/query/reconcile outcomes include relevant group/count context.
• Metrics added for create result, reconcile ticks, detected orphan count, and per-orphan outcome.
• Metric/log behavior is not asserted in tests.
• Alerting/dashboard wiring is outside this diff.

Test execution

• Existence: tests exist and map to the main ACs.
• CI: failing. Test failed in modules/group with panic: Error 1040: Too many connections in TestGroupInviteDetail_IncludesSpaceName_Anonymous; check-sprint failed because linked issue CreateGroup compensating delete is non-atomic → orphan group rows (needs async reconcile) #394 has no Sprint set. Recent main CI runs are green, so this cannot be treated as a verified main-baseline failure from the evidence available here.
• Coverage: no coverage delta evidence found in the PR checks.
• Local tests: not used as pass evidence; QA policy requires CI evidence.

Blockers

1. Get PR CI to a passing state or provide an accepted flaky/baseline classification in CI evidence. At minimum, the PR needs a green Test check for the reviewed head SHA.
2. Fix the check-sprint failure by assigning linked issue CreateGroup compensating delete is non-atomic → orphan group rows (needs async reconcile) #394 to the required Sprint or otherwise rerunning the check after project metadata is corrected.

Risks

1. Add direct metric/log assertions or a lightweight collector assertion if this repo has an established pattern for Prometheus metrics tests.
2. Consider a follow-up for the concurrent teardown/reconcile race and the zero-member orphan semantics; both are narrow but sit on the same consistency path.

_{Labels: review:done:qa:changes (FAIL equivalent in this repo's review label taxonomy) · generated by qa-engineer · not a merge decision.}

[lml2468]

Formal Verdict Aggregate Report — Round 1 — HEAD de9f843

Formal Verdict: REQUEST_CHANGES

Reviewer Summary

• QA (verdict=fail): CI Test job is RED — panic: Error 1040: Too many connections aborts the whole modules/group test binary, so the PR's 7 new tests have no confirmed green run (fail-closed).
• Security (verdict=cleared-with-risk): No new endpoint/auth/credential/dependency; injection & STRIDE clean. Only two low-impact best-practice items (non-parameterized int-typed INTERVAL; un-closed once-per-process Redis client). No security blocker.
• Code (verdict=needs-discussion): Design/correctness/observability solid, no code-level Must; one narrow correctness edge (memberless-orphan flag-flip vs AC-1) + 3 nits. go build/go vet green locally.

Critical Findings (P0/P1 — MUST fix before merge)

• [C-1] CI Test job is RED — source: QA M-1. Run 27703182335: panic: Error 1040: Too many connections in TestGroupInviteDetail_IncludesSpaceName_Anonymous (api_landing_space_info_test.go:159), a pre-existing test not in this diff. Root cause looks like cumulative test-DB connection exhaustion on a resource-constrained runner (log also shows "Memory overcommit must be enabled"), not a logic defect in the PR — and the CI log shows this PR's own tests executing as designed. But a Go panic aborts the entire package binary, so there is no green evidence the 7 new tests pass in CI. Under the fail-closed policy this gates merge. Required: obtain a green CI Test run; if the panic reproduces on re-run, fix the per-test NewTestServer connection-pool accumulation (add pool close / t.Cleanup).

Should-Fix Findings (P2)

• [SF-1] Memberless-orphan flag-flip — source: QA S-1 + Code S-1 (consensus). channel_reconcile.go:240-249: a GroupStatusNormal group with zero subscribable members is flag-flipped to channel_synced=1 without creating an IM channel. Realistic trigger: a partial compensating delete (IM fail → group_member delete OK, group delete fails) leaves a memberless normal group that reconcile then marks "synced" with no backing channel — a narrow gap vs AC-1's literal wording. Low impact (memberless group is effectively dead), but should be resolved: set such groups to Disband, or document the intent. No test covers this branch today.
• [SF-2] Reconcile Redis client not closed on Stop() — source: Security P-2 + QA §6 + Code N-2 (consensus). channel_reconcile.go:149-157,188-193: newRedisReconcileLock opens a dedicated *rd.Client; Close() exists but Stop() never calls it. Once-per-process FD/connection leak — negligible in normal prod, untidy on repeated Start/Stop cycles. Fix: have Stop() close the lock if it implements io.Closer.

Suggestions (P3)

• [SG-1] Non-parameterized INTERVAL literal — source: Security P-1 + Code N-3. db.go QueryReconcilableGroupNos builds the grace predicate via fmt.Sprintf("... INTERVAL %d SECOND)", graceSeconds). Not exploitable (graceSeconds is an int from strconv.Atoi; no client input reaches it), but gosec G201 will flag it. Optional: bind as ? or add // #nosec G201 with rationale.
• [SG-2] Inconsistent group identifier quoting — source: Code N-1. The three new db.go methods mix Update("group") (unquoted) and From("\group`")` (backticked); dbr quotes both correctly, so cosmetic — pick one style.

Questions for Author

• [Q-1] source: QA Q-2. Was the CI Test failure reproduced on a re-run, or is it a one-off resource flake on the runner? A single green re-run clears C-1.
• [Q-2] source: QA Q-1. The check-sprint CI check is also FAILURE — is that a sprint-tracking workflow unrelated to the diff, or does it gate merge?

Verdict Rationale

QA returned fail on a red CI Test job — a fail-closed gate — which by the aggregation rule forces REQUEST_CHANGES regardless of the other lanes. Security cleared (cleared-with-risk, no blocker) and Code found no Must-fix (needs-discussion), so this PR is close to mergeable on substance: the production logic (in-tx channel_synced=0 → confirm IM → flip to 1, else idempotent reconcile), the DEFAULT 1 backward-compat choice, the token-aware Redis lock, and the 7 well-targeted tests are all sound. The dominant blocker is evidentiary, not a code defect — there is simply no green CI run proving the tests pass, because a pre-existing test's connection-exhaustion panic aborts the package binary. Conflict resolution: even though two of three lanes are non-blocking, the hardcoded rule (QA=fail ⇒ REQUEST_CHANGES) governs, and it aligns with prudence here — QA cannot certify an uncertified test suite. Clear C-1 (green Test run) and decide SF-1, and this becomes an APPROVE candidate next round.

Round Context

First round of review for this PR (previous reviewed_sha=none).

[lml2468]

Formal Verdict Aggregate Report — Round 1 — HEAD de9f843

Formal Verdict: REQUEST_CHANGES

Reviewer Summary

Reviewer	Verdict	Headline finding
qa-engineer	fail	Required CI Test job is RED on this HEAD — panic: Error 1040: Too many connections in modules/group (the PR's own package); main is 10/10 green, so not flaky.
security-engineer	cleared	No new trust boundary, request entry point, injection, or credential exposure — only an internal channel_synced flag + idempotent background reconcile worker.
code-reviewer	needs-discussion	Sound eventual-consistency design, 0 code Must-fix; one Should (memberless-orphan masking sits on the AC-1 path) + 4 nits.

Critical Findings (P0-P1)

• [P0-1] modules/group CI Test job — de9f843c — the required Test CI job fails on the reviewing commit: --- FAIL: TestGroupInviteDetail_IncludesSpaceName_Anonymous → panic: Error 1040: Too many connections → FAIL modules/group. Failure is in the exact package this PR modifies; main's last 10 CI runs are all green (0/10 fail), so this is not known-flaky. Fail-closed policy blocks merge. — flagged by qa/B-1 — Fix: eliminate the per-test connection-pool exhaustion (the 7 new channel_reconcile_test.go cases each spin up a fresh testutil.NewTestServer() with no pool reuse/close) — share a test server or close pools — then rerun CI until modules/group is green.

Should-Fix (P2)

• [P2-1] modules/group/channel_reconcile.go:358-367 — the len(uids)==0 branch flips a status=Normal, zero-member orphan to channel_synced=1 without creating a backing IM channel. This residue is reachable via a partial compensating delete (group_member rows removed, then group delete fails), so reconcile can mark a queryable, channel-less group as "synced" — the literal inverse of AC-1. Impact is low (a memberless normal group is effectively inert), which is why it is a Should, not a Must. — flagged by code/S-1 + qa/R-2 — Fix: either transition such groups to Disband, or leave them detectable (don't flip the flag) and alert; add a covering test for the zero-member normal-orphan case.

Suggestions (P3)

• [P3-1] modules/group/channel_reconcile.go:295 — ChannelReconciler.Stop() cancels the goroutine but never closes the dedicated Redis client opened in newRedisReconcileLock (which defines Close()), a once-per-process FD/connection leak across repeated Start/Stop. — flagged by code/N-1 — Fix: have Stop() close r.lock when it implements io.Closer.
• [P3-2] modules/group/channel_reconcile.go:354 — a GetSubscribableMemberUIDs DB member-query failure is counted under metricReconcileOutcomeTotal{outcome="im_fail"}, misdirecting Grafana triage (it is a DB failure, not an IM failure). — flagged by code/N-2 + qa/N-1 — Fix: add a query_fail/member_fail outcome label.
• [P3-3] modules/group/db.go:630 — QueryReconcilableGroupNos builds the grace predicate with fmt.Sprintf("... INTERVAL %d SECOND", graceSeconds) rather than a ?-bind. Not exploitable (graceSeconds is an int from strconv.Atoi on an ops-side env var; no client input reaches it), but it diverges from the parameterized style used elsewhere and gosec G201 will flag it. — flagged by code/N-3 + security (hardening observation) — Fix: Where("created_at < DATE_SUB(NOW(), INTERVAL ? SECOND)", graceSeconds).
• [P3-4] modules/group/db.go — inconsistent group identifier quoting across the three new methods (Update("group") unquoted vs From("group") backticked); cosmetic only, dbr quotes both correctly for MySQL. — flagged by code/N-4 — Fix: pick one style.
• [P3-5] modules/group/metrics.go — the 4 Prometheus metrics (the observability half of AC2) are never asserted in tests, so a regression could silently drop a counter. — flagged by qa/R-1 + code/§3.5 — Fix: at minimum assert metricReconcileOutcomeTotal{outcome="resolved"} increments once.

Questions for Author

• [Q-1] Besides GroupStatusNormal and GroupStatusDisband, are there other group.status values whose rows could be channel_synced=0? QueryReconcilableGroupNos scans only status=GroupStatusNormal, so any orphan in a third status (e.g. frozen/temporary) would never be reconciled. Please confirm the status enum is complete for the reconcile scan. — from qa/Q-1 + code/Q-1

Verdict Rationale

Formal Verdict is REQUEST_CHANGES by the deterministic first-match rule: a P0 finding is present (P0-1), and any P0 → REQUEST_CHANGES. P0-1 is QA's fail-closed blocker — the required Test CI job is RED on the reviewing SHA de9f843c, the failure is in the PR's own modules/group package, and it is confirmed non-flaky (main is 10/10 green). QA's verdict of fail alone precludes an approve.

All three lanes are mutually consistent and converge on the substance: Security cleared with zero findings, Code found 0 Must-fix and rates the eventual-consistency design sound, and QA confirms full functional AC coverage with strong assertions. The divergence in headline verdicts (fail vs cleared vs needs-discussion) reflects each lane's scope, not a contradiction — there are no reviewer disagreements. Cross-reviewer consensus reinforced three items: code/S-1 ↔ qa/R-2 (memberless-orphan masking, P2-1), code/N-2 ↔ qa/N-1 (metric mislabel, P3-2), and code/N-3 ↔ security hardening (unparameterized INTERVAL, P3-3).

Net: this is a high-quality change blocked only by a red required CI job (plus one low-impact Should on the AC-1 path). Once CI Test is green and P2-1 is resolved (or explicitly accepted as out-of-scope), this is an approve candidate on substance. Note: the Check Sprint job is also red — a sprint/process gate, non-code and outside this review's blocking scope, but the merger should be aware of it.

Round Context

First-round review — no prior round context.

---

Generated by review-leader · v5.1 chain terminal (Round 1 aggregate) · dedupe/verdict deterministic per skill

[lml2468]

Formal Verdict: REQUEST_CHANGES — Round 1 (HEAD de9f843c)

Blocked by one P0: the required CI Test job is RED on this SHA (Error 1040: Too many connections in modules/group, the PR's own package; main is 10/10 green, not flaky) — fail-closed. Also one P2 (memberless-orphan flag-flip on the AC-1 path) + 5 suggestions. Security cleared with zero findings; design and tests are otherwise strong.

Full findings: #410 (comment)

Automated bot review; human sign-off still required.

[lml2468]

Formal Verdict Aggregate Report — Round 1 — HEAD de9f843

Formal Verdict: REQUEST_CHANGES

Reviewer Summary

Reviewer	Verdict	Headline finding
qa-engineer	fail	Design + tests are sound and map to both ACs, but the required Test CI job is RED on de9f843c (panic: Error 1040: Too many connections) — no green evidence the 7 new tests passed; fail-closed.
security-engineer	cleared-with-risk (Low)	No new endpoints, trust-boundary, auth, or dependency changes; only 2 non-exploitable hardening items (non-parameterized INTERVAL constant, Redis client not closed on Stop()).
code-reviewer	needs-discussion (Must 0 / Should 2 / Nit 4)	Design is robust and tests are strong, but a zero-member orphan branch silently violates AC1, and the 7 new tests leave no green CI trail.

Critical Findings (P0-P1)

• [P1-1] modules/group/channel_reconcile_test.go (+ setupServiceTest*) — the 7 new tests obtain no green CI evidence: Test job is RED on de9f843c with panic: Error 1040: Too many connections. Root cause: each modules/group case builds a fresh testutil.NewTestServer() MySQL pool with no teardown; the +7 new cases push package-wide connection accumulation past CI MySQL max_connections, and the Go panic aborts the whole package binary. Victim test TestGroupInviteDetail_IncludesSpaceName_Anonymous is pre-existing and green on main (0/10 flakes) → not a known-flaky exemption. — flagged by qa/Blocker B-1 + code/S2 — Fix: close the pool in t.Cleanup (or share one test server) for the new cases / setupServiceTest*, then re-run to a green modules/group on de9f843c.

Should-Fix (P2)

• [P2-1] modules/group/channel_reconcile.go:240-249 — a GroupStatusNormal, zero-subscribable-member orphan is flipped to channel_synced=1 without creating an IM channel, then never re-scanned — a literal AC1 counterexample ("queryable group with no backing IM channel"). Reachable via partial compensating delete (group_member deleted, group delete failed). Impact Low / Reach Rare, but the branch has no test coverage. — flagged by code/S1 + qa/Risk fix: register app_bot and bot_api modules in startup import list #1 — Fix: set such orphans to Disband (semantically no channel needed) or keep them detectable (do not flip the flag) + alert, rather than silently marking synced; add a zero-member reconcile test.

Suggestions (P3)

• [P3-1] modules/group/channel_reconcile.go:236 — a DB/member-query failure from GetSubscribableMemberUIDs is counted under metricReconcileOutcomeTotal{outcome="im_fail"}, misleading Grafana triage. Add a member_fail/query_fail label. (flagged by code/N1 + qa/N-1)
• [P3-2] modules/group/db.go:71 — QueryReconcilableGroupNos uses fmt.Sprintf("... INTERVAL %d SECOND", graceSeconds) instead of ? binding. Currently non-exploitable (int type, ops env var, not client-reachable) but trips gosec G201 and is inconsistent with the file's parameterized style. Prefer Where("created_at < DATE_SUB(NOW(), INTERVAL ? SECOND)", graceSeconds). (flagged by security/Risk fix: register app_bot and bot_api modules in startup import list #1 + code/N2)
• [P3-3] modules/group/channel_reconcile.go:150 (Stop()) — ChannelReconciler.Stop() is never wired to a shutdown hook and redisReconcileLock.Close() is never called; the goroutine + Redis client live for the process lifetime. Consistent with the oidc precedent, reclaimed on process exit → low risk. Optional: close the lock if it implements io.Closer. (flagged by security/Risk YUJ-446: docker/octo OSS deployment hardening (5 bug fixes) #2 + code/N3)
• [P3-4] modules/group/service.go:1150 — markChannelPendingTx does an INSERT (column DEFAULT 1) immediately followed by an UPDATE to 0, one extra write per group create. Design rationale (avoiding channel_synced on the Model) is documented and acceptable; pure efficiency/style note. (flagged by code/N4)
• [P3-5] Observability half of AC2 is untested — metrics and structured logs exist but no test asserts any counter, so a regression could silently drop counts. Suggest at least asserting channel_reconcile_outcome_total{outcome="resolved"} increments once. (flagged by qa/Risk YUJ-446: docker/octo OSS deployment hardening (5 bug fixes) #2 + code Risk Register)

Questions for Author

• None. QA raised a state-enum completeness question (does QueryReconcilableGroupNos scanning only GroupStatusNormal miss a third state?); the code reviewer's contrarian pass confirmed GroupStatus has only {Normal, Disband} and that excluding Disband is intentional — see Verdict Rationale.

Verdict Rationale

REQUEST_CHANGES follows the deterministic rule table: no P0, but ≥1 P1 (the CI blocker P1-1) → REQUEST_CHANGES. This aligns with the strongest upstream signal — QA's fail-closed fail — because the PR's own 7 tests have no green CI trail on de9f843c; the whole modules/group binary panics on connection exhaustion before results are recorded. Code review independently reached needs-discussion (Must 0 / Should 2), and its S2 pins the same CI failure to a fixable root cause (per-test pools with no teardown). The second Should-fix (P2-1, zero-member orphan) is a genuine AC1 edge counterexample that both QA and code converged on. Security is cleared-with-risk at Low severity with only two optional hardening items — it does not block, and its two risks are captured as P3-2/P3-3.

Cross-reviewer note (disagreement resolved): QA flagged the reconcile status-enum scan as a possible completeness gap (open question). The code reviewer's adversarial pass traced const.go and confirmed only two statuses exist and Disband is deliberately excluded — the concern is a non-issue, so no Question is carried forward. No findings were silently dropped.

Non-blocking for this review: the check-sprint CI check is also RED, but it is a sprint-process gate (issue #394 has no Sprint set), not a code defect — the merger should be aware but it is out of this review's scope.

Round Context

First-round review — no prior round context.

---

Generated by review-leader · chain terminal (Round 1 aggregate) · dedupe/verdict deterministic per skill

[lml2468]

REQUEST_CHANGES — Round 1 (HEAD de9f843c)

The required Test CI job is RED on this SHA (panic: Error 1040: Too many connections), so the PR's 7 new tests have no green trail — fail-closed. There's also one Should-fix: a zero-member Normal orphan is marked channel_synced=1 without an IM channel (AC1 counterexample).

Top findings: [P1-1] CI connection-pool exhaustion in new modules/group tests · [P2-1] zero-member orphan flag-flip at channel_reconcile.go:240-249.

Full consolidated findings: #410 (comment)

Automated bot review; human sign-off still required.

[lml2468]

Formal Verdict Aggregate Report — Round 1 — HEAD de9f843

Formal Verdict: REQUEST_CHANGES

Lens Summary

Lens	Verdict	Headline
code	approved-with-nits	Product logic is correct and well-verified; only test-hygiene + a graceful-shutdown gap.
security	cleared	No exploitable surface — SQL uses %d/bind params, lock token is crypto-random, membership uses live filtered UIDs.
qa	needs-discussion	Required Test CI check is RED (MySQL "Too many connections"); PR's "go test green" claim is contradicted.

Critical Findings (P0-P1)

无 Critical / High priority findings — no data-loss, no exploitable vuln, no functional-AC defect in product code. The blocker is a red required check + test debt, not broken behavior.

Should-Fix (P2)

• [P2-1] CI is red — required Test check fails on this SHA. modules/group panics Error 1040: Too many connections in the unrelated pre-existing test TestGroupInviteDetail_IncludesSpaceName_Anonymous (api_landing_space_info_test.go:159). Root cause: testutil.NewTestServer() opens a fresh per-Context MySQL pool (MaxOpenConns=100 / MaxIdleConns=10) that is never closed — no Context.Close, no t.Cleanup in service_test.go:14-33. The package now has ~163 such leaked pools (156 before this PR); this PR's +7 reconcile tests aggravate an already-saturated pool. The PR description's claim "full go test ./modules/group/ green" is contradicted by CI (likely a higher local max_connections). — flagged by code/C-1 + qa/Q-1 — Fix: reconcile the green-claim vs red CI and get the package reliably green before merge — ideally fix the harness leak in octo-lib (NewTestServer should return a closer / register cleanup), or at minimum have the 7 new tests share one server via TestMain / package setup. Do not merge on a red required check.
• [P2-2] modules/group/channel_reconcile.go:220 (Start) + api.go:90 (startChannelReconciler) — the worker's start/scheduling and prod wiring are untested; all tests construct the reconciler directly and call RunOnce. A regression that no-ops startChannelReconciler would leave orphans unrecovered yet pass all 7 tests. — flagged by qa/Q-2 — Fix: add a test asserting startChannelReconciler wires a non-nil reconciler with the expected interval/grace, or a short-interval Start()-drives-RunOnce test.
• [P2-3] modules/group/channel_reconcile_test.go — coverage gaps: (a) Redis lock path is never exercised (all tests pass lock=nil, so Acquire/Release/lock_held/lock_err at RunOnce are untested); (b) the flag_fail branch (IM recreate OK but MarkChannelSynced UPDATE fails) is untested; (c) the backward-compat claim (channel_synced DEFAULT 1 for non-CreateGroup insert paths / existing rows) is asserted only via the DDL default, never by a test that inserts via another path and reads back 1. — flagged by qa/Q-3 — Fix: add targeted tests for the lock path, a flag_fail injection, and a non-CreateGroup insert asserting channel_synced=1.

Suggestions (P3)

• [P3-1] modules/group/api.go:90 — the group register.Module wires no Stop hook (unlike oidc's Stop: o.Close), so ChannelReconciler.Stop() is dead in prod and an in-flight RunOnce is cut on SIGTERM. Not a leak (process-lifetime singleton; recreate is idempotent so next boot recovers), just a graceful-shutdown asymmetry. — flagged by code/C-2
• [P3-2] modules/group/channel_reconcile_test.go:31 (seedOrphanGroup) — hardcodes the group insert column list; a future NOT-NULL column without a DB default would silently break all reconcile tests. — flagged by qa/Q-4

Questions for Author

• [Q-1] Is main's Test check currently reliably green? If main is also intermittently red with Error 1040, this PR merely surfaces pre-existing infra debt (P2-1 stays Should-Fix); if main is reliably green, the +7 pools are the tipping trigger and P2-1 becomes a hard merge blocker. — from qa/Q-Q-1
• [Q-2] What is max_connections on the CI MySQL? At the default ~151, 163 leaked pools guarantee exhaustion. — from qa/Q-Q-2

Verdict Rationale

REQUEST_CHANGES. No lens returned a hard block (security clear, code comment, qa comment) and the product code is sound — the code lens verified and cleared several tempting candidates (dbr auto-quotes Update("group"); non-tx MarkChannelSynced is correct post-commit; LockTTL=Interval is safe given idempotency; no promauto double-register), and security confirmed no injection/lock/authz/DoS/PII surface. However, two independent conditions gate the merge: (1) the required Test CI check is red on this exact SHA and the PR description asserts the package tests are green — that contradiction must be resolved; and (2) after dedupe there are 3 Should-Fix (P2) items clustered on test reliability/coverage. Per the deterministic rule (no P0, ≥3 P2) and the fail-closed principle of never approving over a failing required check, the verdict is REQUEST_CHANGES. Note the cross-lens nuance preserved: QA assesses the red CI as pre-existing harness debt marginally aggravated by this PR (HIGH confidence on mechanism, MEDIUM on this PR being the tipping trigger) rather than a functional defect — hence Should-Fix, not a P0.

Round Context

ROUND=1: First-round review — no prior round context.

File Coverage Matrix (union across lenses)

File	Reviewed?	Findings refs
modules/group/api.go	✅ code	C-2 / P3-1, P2-2
modules/group/channel_reconcile.go	✅ code, security, qa	P2-2, P2-3
modules/group/channel_reconcile_test.go	✅ code, qa	P2-1, P2-3, P3-2
modules/group/db.go	✅ code, security	(cleared: quoting, injection)
modules/group/metrics.go	✅ code	(cleared: no double-register)
modules/group/service.go	✅ code, security	(cleared: injection point)
modules/group/sql/20260617000001_group_channel_synced.sql	✅ security, qa	(cleared: DDL guard)

Notes

• Confidence filter aggregate: code dropped 3 candidates (unquoted-group SQL error, LockTTL race, promauto double-register) after source verification; security emitted 0 findings (no candidate cleared 0.50); qa preserved a contrarian read (did not grade fail because the red is pre-existing harness debt, not a product defect). No lens returned UNKNOWN — all 3 subagents completed.
• Redaction: GH copy passed through redact-report.sh; multica copy is raw.
• Terminal chain: this comment is the last artifact for Round 1; a next round is triggered by the spawner only on a new HEAD SHA.

---

Generated by review-agent · chain terminal (Round 1 aggregate) · dedupe/verdict deterministic · 3-lens parallel

[lml2468]

Formal Verdict: REQUEST_CHANGES (Round 1 · de9f843)

Product code is sound — security lens clear, code logic verified (dbr quoting, non-tx flip, lock TTL, idempotency all correct). Blocking on two things, not broken behavior:

1. The required Test CI check is red on this SHA — modules/group panics Error 1040: Too many connections; the PR description's "go test ./modules/group/ green" is contradicted. Root cause is a package-wide NewTestServer pool leak (no t.Cleanup/Close), aggravated by the +7 new tests. Please get the package reliably green (ideally fix the harness leak) and reconcile the green-claim before merge.
2. Test coverage gaps: worker Start()/prod wiring, the Redis lock path, the flag_fail retry branch, and the DEFAULT-1 backward-compat claim are all unexercised.

Full findings + questions in the aggregate comment.

[github-actions]

This pull request has been automatically marked as stale due to inactivity. Please add an update or it will be closed.

[github-actions]

Closing due to inactivity. If you believe this PR should be revived, please open a new issue or contact a maintainer.