docs(dnn): Option C connection-string prep for idle-hang (prep-only, jsboige arbitration)

[jsboige]

What

Prep-only analysis for the intermittent idle-hang on the prod DNN site (https://dnn.argumentum.myia.io, observed during audit #662 §6). Documents the Option C mitigation (SQL connection-string tuning) with recommended values + rationale + apply-steps, for jsboige's arbitration (prod web.config = ops/VPS lane). Not applied.

Idle task from ai-01 dispatch 8b3ymj.

Symptom & root-cause hypothesis

First probes after an idle period → HTTP 000, then recovers to 200 once re-warmed. Idle-correlated, intermittent. Most likely cause: SQL connection-pool staleness post-idle — the ADO.NET pool holds a connection whose underlying socket went dead (SQL Server reclamation / NAT-firewall idle timeout); the next request grabs the dead entry and blocks on Open/first-query until timeout.

Option C — recommended values

Apply to SiteSqlServer in prod web.config (on the VPS — repo copy is a placeholder):

Min Pool Size=5; Connect Timeout=30; Connection Lifetime=300; Load Balance Timeout=30

• Connection Lifetime=300 — shed connections older than 5 min; the most relevant knob for the symptom (stale entries can't linger long enough to be served).
• Min Pool Size=5 — pre-warm; first request after idle skips the cold-connect cost.
• Connect Timeout=30 — explicit; bounds the worst-case stall and fails fast with a clear error.
• Load Balance Timeout=30 — reclaim idle connections so the pool doesn't hold dead sockets through a quiet period.

Composes with Option A

Option A (IIS PeriodicRestart ~4h, already GO'd to the IIS lane) bounds the problem at 4h. Option C hardens the pool within the recycle window. Independent and stackable; either alone helps.

Gate boundaries

• ❌ Not applied — no prod write, no VPS access, no web.config mutation.
• ✅ Values + rationale + apply-steps documented for jsboige.
• Fully reversible (remove the 4 params to restore defaults). No schema/app-code/DNN-version impact.

Recommendation

Decision = jsboige. Sequencing: apply Option A first (bounds the problem), then layer Option C if within-window stalls persist. Confirm root cause on the VPS before relying on Option C alone.

Relates: #662 (audit, idle-hang §6), dispatch 8b3ymj.

🤖 Worker po-2023 (GLM)

[clusterManager-Myia]

[NanoClaw] — LGTM

Docs-only prep (+108/-0, single new file docs/dnn/dnn-hang-option-c-connection-string-prep.md), verified firsthand:

• Technical claims sound — all 4 recommended keywords are canonical ADO.NET SqlClient, and the documented defaults match Microsoft reference (Min Pool Size=0, Connect Timeout=15s, Connection Lifetime=0, Load Balance Timeout=0). The §4 note distinguishing the two age-caps (Lifetime = total age, Load Balance Timeout = idle age) is correct and pedagogically useful — these are genuinely independent knobs, easily conflated.
• Root-cause hypothesis coherent — pool-staleness post-idle (dead socket reclaimed by SQL Server / NAT-firewall idle timeout, handed to next request → blocks on Open) is the textbook explanation for idle-correlated HTTP 000 that recovers on warm-up. Matches the observed signature.
• Cross-refs resolve — ../investigations/2026-07-03-dnn-prod-rules-coverage.md EXISTS (6908B); #662 is the real audit (closed); the Option A / Option C complementarity framing is consistent.
• Gate boundaries honest — explicitly not applied (prod web.config = VPS/ops lane, repo copy is a placeholder Data Source=REPLACE); fully reversible; no schema/app-code/DNN-version impact. §7 "confirm root cause on the VPS before relying on Option C alone" is the right caution — if the hang turns out to be JIT/app-domain cold-start rather than pool staleness, these params won't help.

Decision = jsboige (ops lane). Sound analysis, no concerns.