Always attempt a resume, and let the server decide continuity

RTN14h - implemented. Replaces RTN15g as of specification 6.1.0. The client discarded
its connection state once connectionStateTtl had passed and reconnected fresh, throwing
away a resume the server would still have honoured. DF1a settles the scope - the ttl is
no longer used to decide whether to resume at all - so the gate is general rather than
SUSPENDED-only, which is how ably-js reads it too.
RTN27c - fixed. DISCONNECTED is a state where "if the library was previously connected,
the next connect attempt will be an RTN15b resume attempt". Clearing the key on every
failed attempt made that false from the second attempt onwards.
RTN8d, RTN9d - fixed twice over. Both list only CLOSED, CLOSING and FAILED, so SUSPENDED
must keep the key and id; it cleared them. And all three of the states they do name cleared
after SetState, which is what emits the state change - inline, with no SynchronizationContext
installed - so the application was told it had reached a terminal state while Connection.Key
still read as a resumable key. The clear now happens before the transition, which also stops
it depending on a finally. Only a listener reading during the transition could observe this,
so it was inherited rather than introduced here.
RTN15g1, RTN15g2, RTN15g3 - deleted at 6.1.0. HasConnectionStateTtlPassed and its tests
go with them. The reattach RTN15g3 asked for is already unconditional under RTL3d.
RTL4j, RTL4j1, RTL4j2 - deleted at 6.1.0; SDKs need not set ATTACH_RESUME. Safe only
because RTL4c1 already sends channelSerial on ATTACH and RTL15b2 keeps it across a
suspend, so the reattach still carries a continuity signal. The Flag constant stays,
per TR3f.

The now-dead clearConnectionKey parameter goes from SetDisconnectedStateCommand and
SetSuspendedStateCommand. No caller sets it, and leaving it would let the violation back
in unnoticed. SetConnectingStateCommand keeps its own, still used by ConnectionClosingState
for RTN11b/RTN11d, where a clean connection is the intent.

Two clauses the 6.1.0 edit left describing the old model. They are handled differently, and
both deliberately:
 - RTN27d is not followed. It still calls SUSPENDED a state whose "next connect attempt is
   a clean connection (not a resume attempt)", which RTN14h, RTN8d, RTN9d and DF1a now all
   contradict; the commit that made those changes does not touch RTN27 at all. ably-js
   retains the key in SUSPENDED too, citing RTN8d/RTN9d and RTN14h for it.
 - RTN16g2 is followed. It says createRecoveryKey returns null in SUSPENDED, which sits
   oddly beside RTN9d now that a key exists there, but it is what the published spec says
   and CreateRecoveryKey still complies. ably-js returns a key instead, citing an RTN16g3
   that "replaces RTN16g2 as of 6.1.0" and appears nowhere in the published spec.
Both worth raising upstream rather than guessing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: AndyTWF

src/IO.Ably.Shared/Realtime/RealtimeChannel.cs

@@ -28,12 +28,6 @@ internal class RealtimeChannel : EventEmitter<ChannelEvent, ChannelStateChange>,
         private readonly PushChannel _pushChannel;
         private int _retryCount = 0;
 
-        /// <summary>
-        /// True when the channel moves to the @ATTACHED@ state, and False
-        /// when the channel moves to the @DETACHING@ or @FAILED@ states.
-        /// </summary>
-        internal bool AttachResume { get; set; }
-
         private int _decodeRecoveryInProgress;
 
         // We use interlocked exchange because it is a thread safe way to read a variable
@@ -160,33 +154,22 @@ internal void ConnectionStateChanged(ConnectionStateChange connectionStateChange
                     }
 
                     /*
-                     * (RTL3d, RTN19b, RTN15c6, RTN15c7, RTN15g3) On entering CONNECTED, every
-                     * channel that was attached or pending needs its ATTACH - or its DETACH - sent
-                     * again, because the previous transport will never answer.
+                     * On entering CONNECTED, every channel that was attached or pending needs its
+                     * ATTACH - or its DETACH - sent again; the previous transport will never answer.
                      *
                      * The two branches have different owners. RTL3d names ATTACHING, ATTACHED and
-                     * SUSPENDED and asks for an RTL4c attach. DETACHING is not in that list and is
-                     * not a state transition at all - it is RTN19b, "if there are any pending
-                     * channels i.e. in the ATTACHING or DETACHING state, the respective ATTACH or
-                     * DETACH message should be resent". ably-js splits it the same way, with
-                     * checkPendingState handling both pending operations and notifyState the
-                     * reattach.
+                     * SUSPENDED, and asks for an RTL4c attach. DETACHING is RTN19b instead, which
+                     * requires the respective ATTACH or DETACH of any pending channel to be resent.
+                     * ably-js splits it the same way, between checkPendingState and notifyState.
                      *
                      * RTL3d1 requires all of this to be applied before CONNECTED reaches external
-                     * listeners, and is why it lives here rather than in HandleConnectedCommand:
-                     * Connection.NotifyUpdate runs the internal handlers, which is what calls this,
-                     * before handing the emit to NotifyExternalClients.
-                     *
-                     * Unconditional, deliberately. This used to be gated on the connectionId having
-                     * changed, which silently skipped the RTN15g3 reattach: RTN15g empties
-                     * Connection.Id *before* the CONNECTING transition, so by the time CONNECTED
-                     * arrived the id being compared against had already gone and the channel
-                     * concluded nothing had changed. The channel stayed locally ATTACHED on a brand
-                     * new connection with no server-side attachment - permanently silent.
+                     * listeners, which is why it lives here: Connection.NotifyUpdate runs the
+                     * internal handlers, this among them, before the emit.
                      *
-                     * Whether the connection was resumed belongs inside the ATTACH, in channelSerial
-                     * and the ATTACH_RESUME flag, rather than in a decision about whether to send
-                     * one at all. ably-js reattaches unconditionally for the same reason.
+                     * Unconditional, deliberately. Whether the connection was resumed belongs
+                     * inside the ATTACH, in the channelSerial RTL4c1 carries, rather than in a
+                     * decision about whether to send one at all. ably-js reattaches unconditionally
+                     * for the same reason.
                      */
                     switch (State)
                     {
@@ -371,11 +354,6 @@ ProtocolMessage CreateAttachMessage()
                     message.SetModesAsFlags(Options.Modes);
                 }
 
-                if (AttachResume)
-                {
-                    message.SetFlag(ProtocolMessage.Flag.AttachResume);
-                }
-
                 return message;
             }
         }
@@ -748,11 +726,9 @@ private void HandleStateChange(ChannelState state, ErrorInfo error, ProtocolMess
                     break;
                 case ChannelState.Detaching:
                     AttachedAwaiter.Fail(new ErrorInfo("Channel transitioned to detaching", ErrorCodes.InternalError));
-                    AttachResume = false;
                     break;
                 case ChannelState.Attached:
                     _retryCount = 0;
-                    AttachResume = true;
                     break;
                 case ChannelState.Detached:
                     /* RTL13a check for unexpected detach */
@@ -792,7 +768,6 @@ an attempt to reattach the channel should be made immediately */
                     break;
                 case ChannelState.Failed:
                     _retryCount = 0;
-                    AttachResume = false;
                     AttachedAwaiter.Fail(error);
                     DetachedAwaiter.Fail(error);
                     Presence.ChannelDetachedOrFailed(error);

src/IO.Ably.Shared/Realtime/Workflows/RealtimeCommands.cs

@@ -204,13 +204,12 @@ protected override string ExplainData()
 
     internal class SetDisconnectedStateCommand : RealtimeCommand
     {
-        private SetDisconnectedStateCommand(ErrorInfo error, bool retryInstantly, bool skipAttach, Exception exception, bool clearConnectionKey)
+        private SetDisconnectedStateCommand(ErrorInfo error, bool retryInstantly, bool skipAttach, Exception exception)
         {
             Error = error;
             RetryInstantly = retryInstantly;
             SkipAttach = skipAttach;
             Exception = exception;
-            ClearConnectionKey = clearConnectionKey;
         }
 
         public ErrorInfo Error { get; }
@@ -221,45 +220,36 @@ private SetDisconnectedStateCommand(ErrorInfo error, bool retryInstantly, bool s
 
         public Exception Exception { get; }
 
-        public bool ClearConnectionKey { get; }
-
         protected override string ExplainData()
         {
             return $"RetryInstantly: {RetryInstantly}" +
                    "SkipAttach: " + SkipAttach +
                    ((Error != null) ? " Error: " + Error : string.Empty) +
-                    ((Exception != null) ? " Exception: " + Exception.Message : string.Empty) +
-                " ClearConnectionKey: " + ClearConnectionKey;
+                    ((Exception != null) ? " Exception: " + Exception.Message : string.Empty);
         }
 
         public static SetDisconnectedStateCommand Create(
             ErrorInfo error,
             bool retryInstantly = false,
             bool skipAttach = false,
-            Exception exception = null,
-            bool clearConnectionKey = false)
-            => new SetDisconnectedStateCommand(error, retryInstantly, skipAttach, exception, clearConnectionKey);
+            Exception exception = null)
+            => new SetDisconnectedStateCommand(error, retryInstantly, skipAttach, exception);
     }
 
     internal class SetSuspendedStateCommand : RealtimeCommand
     {
-        private SetSuspendedStateCommand(ErrorInfo error, bool clearConnectionKey)
+        private SetSuspendedStateCommand(ErrorInfo error)
         {
             Error = error;
-            ClearConnectionKey = clearConnectionKey;
         }
 
         public ErrorInfo Error { get; }
 
-        public bool ClearConnectionKey { get; }
-
-        public static SetSuspendedStateCommand Create(ErrorInfo error, bool clearConnectionKey = false) => new SetSuspendedStateCommand(error, clearConnectionKey);
+        public static SetSuspendedStateCommand Create(ErrorInfo error) => new SetSuspendedStateCommand(error);
 
         protected override string ExplainData()
         {
-            var message = (Error != null) ? " Error: " + Error : string.Empty;
-            message += " ClearConnectionKey:" + ClearConnectionKey;
-            return message;
+            return (Error != null) ? " Error: " + Error : string.Empty;
         }
     }
 

src/IO.Ably.Shared/Realtime/Workflows/RealtimeState.cs

@@ -80,43 +80,6 @@ public ConnectionStateChange UpdateState(ConnectionStateBase state, ILogger logg
                 return new ConnectionStateChange(connectionEvent, oldState, newState, state.RetryIn, ErrorReason);
             }
 
-            public bool HasConnectionStateTtlPassed(Func<DateTimeOffset> now)
-            {
-                if (ConfirmedAliveAt.HasValue == false)
-                {
-                    // Nothing has ever been received on this client, so there is no connection
-                    // state to consider stale.
-                    return false;
-                }
-
-                // RTN15g2 - the window is connectionStateTtl plus maxIdleInterval, measured from
-                // the last known sign of activity from Ably rather than from when we left the
-                // Connected state. A device that slept may only have left Connected moments ago
-                // having last actually heard from Ably hours earlier.
-                // Clamped at zero rather than coalesced, because nothing between the wire and here
-                // validates the sign: TimeSpanJsonConverter will hand back a negative TimeSpan for a
-                // negative number and Update assigns it as-is. A negative value would make the
-                // subtraction below throw OverflowException, which is precisely the failure this
-                // method was rewritten to remove - the throw escapes HandleSetStateCommand's
-                // AblyException-only catch, gets logged and dropped by the command loop, and leaves
-                // the client wedged in DISCONNECTED with no transport and no retry. The RTN23a
-                // monitor already treats a non-positive interval as no promise at all.
-                var maxIdleInterval = MaxIdleInterval > TimeSpan.Zero ? MaxIdleInterval.Value : TimeSpan.Zero;
-
-                if (ConnectionStateTtl >= TimeSpan.MaxValue - maxIdleInterval)
-                {
-                    // The window cannot be represented, so it can never elapse.
-                    return false;
-                }
-
-                // Deliberately a subtraction rather than ConfirmedAliveAt + window. Adding to a
-                // DateTimeOffset throws ArgumentOutOfRangeException once the result runs past
-                // DateTimeOffset.MaxValue, and that exception escaped into the command loop where
-                // it was logged and dropped - silently abandoning whichever state transition was
-                // in progress. Comparing two durations cannot fail that way.
-                return now() - ConfirmedAliveAt.Value > ConnectionStateTtl + maxIdleInterval;
-            }
-
             public void Update(ConnectionInfo info, bool isUpdate)
             {
                 // Guarded differently on purpose. connectionId is a top-level field and always