Questions and decisions

Round 1

Q1. Which outcome should this task authorize: wait for and upgrade to the first released Rails version containing the upstream pub/sub lifecycle fix, carry a bounded Hive-maintained backport until that release is usable, or retain the existing `StatusChannel#stream_from` override with an explicit removal trigger?

A1.

Retain the existing StatusChannel#stream_from override with an explicit removal trigger: the first released Rails gem containing the authoritative upstream lifecycle fix that passes Hive's focused and full Web verification. Do not carry a broader framework backport.

Q2. What dependency boundaries are non-negotiable—for example, must Hive remain on released Rails gems only, may it pin a Git commit or prerelease, and is a temporary patch/vendored framework file acceptable?

A2.

Hive must remain on released Rails gems. Do not pin a Git commit or prerelease and do not vendor or patch framework files. Keep the narrow application override until a released authoritative implementation is usable.

Q3. Is removing `StatusChannel#stream_from` part of this task's immediate acceptance criteria, or should removal occur only after the authoritative Rails implementation is present and verified in Hive?

A3.

Removal is not immediate acceptance. Remove the override only after the authoritative released Rails implementation is present in Hive and verified against the full race contract.

A4.

All listed behaviors are mandatory: teardown before deferred subscribe, teardown after registration, exactly-once unsubscribe, no confirmation after teardown, no leaked handlers, adapter subscribe failure, and preserved callback and coder semantics.

Q5. What verification and rollout evidence is required before the chosen approach is accepted—for example, focused channel tests, the full web suite, adapter-specific coverage, repeated/stress execution, and a documented rollback or removal condition?

A5.

Require focused channel tests, the full Web suite, adapter-specific coverage, repeated stress execution of the race windows, and exact evidence of the Rails version and upstream fix. Document the rollback path and the precise future removal condition for the override.

Requirements

Actor: Hive Web maintainers responsible for Rails dependency updates and the StatusChannel lifecycle contract.
Flow: Keep the narrow StatusChannel#stream_from override while Hive uses a released Rails gem without the authoritative upstream lifecycle fix. Do not pin a commit or prerelease, vendor framework code, or carry a broader backport.
Flow: When a released Rails gem includes the upstream fix, record the exact Rails version and upstream fix, upgrade Hive, remove the override, and verify the same race contract against the framework-owned implementation.
Flow: If the released implementation fails any required verification, use the documented rollback path and retain or restore the override until a later released version passes.
Acceptance example: Given teardown occurs before deferred subscription or after registration, the focused tests prove no late confirmation, no leaked handler, and exactly-once unsubscribe.
Acceptance example: Given pub/sub subscription fails, the channel recovers without leaking lifecycle state; callback and coder semantics remain unchanged on successful subscriptions.
Acceptance example: Before removal is accepted, focused channel tests, adapter-specific coverage, repeated stress runs across both race windows, and the full Web suite all pass with evidence tied to the exact released Rails version and upstream fix.
Acceptance example: If any focused, adapter, stress, or full-suite check fails after removal, the authoritative Rails implementation is not yet usable in Hive and the override remains in place.