SessionLoop is a 922-line transport, protocol, lifecycle, and credential coordinator

[nficano]

Summary

Second-pass well-written-code audit finding. SessionLoop is carrying too many runtime responsibilities in one 922-line class, making protocol behavior harder to review and increasing the risk of regressions when one flow changes.

Evidence

• arcp-runtime/src/main/java/dev/arcp/runtime/session/SessionLoop.java:74 through arcp-runtime/src/main/java/dev/arcp/runtime/session/SessionLoop.java:77 documents that the class owns handshake, dispatch, job lifecycle, heartbeats, lease enforcement, idempotency, and subscribe fan-out.
• arcp-runtime/src/main/java/dev/arcp/runtime/session/SessionLoop.java:78 declares the single SessionLoop class.
• The file currently has 922 lines.
• The same class contains handlers such as handleListJobs at arcp-runtime/src/main/java/dev/arcp/runtime/session/SessionLoop.java:331 and handleSubmit at arcp-runtime/src/main/java/dev/arcp/runtime/session/SessionLoop.java:395.

Why it matters

This is a high-churn protocol boundary. Keeping transport subscription, handshake, list jobs, submit, subscribe, credential binding, heartbeat, and shutdown logic in one class makes local reasoning difficult and encourages broad, fragile changes.

Proposed fix

Split cohesive handlers behind small collaborators, for example SessionHandshake, ListJobsHandler, SubmitHandler, SubscriptionHandler, and SessionWriter, while keeping SessionLoop as orchestration glue.

Acceptance criteria

• SessionLoop no longer contains the list-jobs, submit, subscribe, and credential issuance implementations directly.
• Each extracted handler has focused tests around its behavior.
• The file-level size drops substantially and no new broad suppressions are added.