# each line is a message i'd like to surface
yeah, based pushback. the pdf path is a confirmed 4 gb capacity bomb, but calling it the singular incident root was too strong while queue concurrency is still unmodeled. i'm auditing the whole worker topology now, per queue, per replica, fleet-wide, plus any handler-local promise.all fanout. no action on sitemap or redis logging. for logtail, i'll separate app exceptions from transport exceptions, those are very different aura.
first big finding, the config is lying. concurrency: 1 is never read. actual topology is one loop per unique queue per api replica. there are 16 queues, so one api task can run 16 jobs at once, current 5-task prod can run 80, rolling deploy ceiling is 160. each queue itself is capped at 5 current, 10 during surge. this makes the isolation concern way less sus, but i'm still tracing handler-local fanout before judging the strat.
yeah, highkey feasible. vscode terminal persistence is basically detached process ownership plus a reconnect token, and our current backend is doing the opposite, it owns child stdio directly and kills every harness in stop(). the locked-in version would be a tiny per-harness supervisor process that survives backend death, owns stdin/stdout plus a bounded replay log, and lets a new backend reattach by session id. i’m checking vscode’s exact persistence contract and our host protocol before i call the shape, but this could absolutely make restarts way less scary without building a whole daemon empire.
stages 3 and 4 are implemented and isolated packaging is clean. next is reviewer closure, fix anything real, check those two todo boxes, then another install/restart plus your manual vibe check. active backend is still the known-good pid 49570, i have not restarted it onto this batch yet.