Update duplicate-finding script to handle Chat too

That is, multiple spec files and hyphens in spec point identifiers.

Rename the existing duplicates (I’ll add a comment on the PR so that consumers
of the spec can update their implementations.)

scripts/find-duplicate-spec-items

@@ -3,20 +3,33 @@
 # Script to detect duplicate spec IDs in the client library spec
 # This tends to happen when concurrent spec PRs are merged
 
-SPEC_PATH = File.expand_path('../../textile/features.textile', __FILE__)
-
-File.read(SPEC_PATH).scan(/\*\s\@\((\w+)\)\@/).group_by do |match|
-  match
-end.select do |spec_id, matches|
-  matches.count > 1
-end.each do |spec_id, matches|
-  puts "#{spec_id.first} has #{matches.count - 1} duplicate(s)"
-end.tap do |matches|
-  if matches.empty?
-    puts "✓ Spec is valid. No duplicates found"
-  else
-    puts "\n✘ INVALID SPEC: #{matches.count} duplicate(s) found"
-    exit 1
+SPEC_FILES = ["features", "chat-features"]
+
+has_errors = false
+
+SPEC_FILES.each_with_index do |spec_file, i|
+  file_name = "#{spec_file}.textile"
+
+  puts "Checking #{file_name}"
+
+  spec_path = File.expand_path("../../textile/#{file_name}", __FILE__)
+
+  File.read(spec_path).scan(/\*\s\@\(([\w-]+)\)\@/).group_by do |match|
+    match
+  end.select do |spec_id, matches|
+    matches.count > 1
+  end.each do |spec_id, matches|
+    puts "#{spec_id.first} has #{matches.count - 1} duplicate(s)"
+  end.tap do |matches|
+    if matches.empty?
+      puts "✓ Spec is valid. No duplicates found"
+    else
+      puts "\n✘ INVALID SPEC: #{matches.count} duplicate(s) found"
+      has_errors = true
+    end
   end
+
+  puts if i < SPEC_FILES.count - 1
 end
 
+exit 1 if has_errors

textile/chat-features.textile

@@ -37,7 +37,7 @@ h3(#rooms-status). Room Statuses
 
 The status of any given Chat Room is the combination of the states of all of its constituent contributors. For more information on this, see "@Room Lifecycle@":#rooms-lifecycle.
 
-* @(CHA-RS1)@ Every room has a @status@, which describes the current status of the room. 
+* @(CHA-RS1)@ Every room has a @status@, which describes the current status of the room.
 ** @(CHA-RS1j)@ The @INITIALIZING@ status is the initial status as the room is setting itself up.
 ** @(CHA-RS1a)@ The @INITIALIZED@ status is the initial status before any attachment operations have taken place.
 ** @(CHA-RS1b)@ The @ATTACHING@ status is used when the room is in the process of attaching to Ably.
@@ -79,7 +79,7 @@ h4(#rooms-lifecycle-operations). Room Lifecycle Operations
 
 * @(CHA-RL1)@ A room must be explicitly attached via the @ATTACH@ operation.
 ** @(CHA-RL1a)@ @[Testable]@ If the room is already in the @ATTACHED@ status, then this operation is no-op.
-** @(CHA-RL1h)@ If the room is in the @INITIALIZING@ status, then it must wait for the in-progress @RELEASING@ operation from a previous room instance to complete before proceeding.
+** @(CHA-RL1j)@ If the room is in the @INITIALIZING@ status, then it must wait for the in-progress @RELEASING@ operation from a previous room instance to complete before proceeding.
 ** @(CHA-RL1b)@ @[Testable]@ If the room is in the @RELEASING@ status, the operation shall be rejected with an @ErrorInfo@ with the @RoomIsReleasing@ error code from the "chat-specific error codes":#error-codes.
 ** @(CHA-RL1c)@ @[Testable]@ If the room is in the @RELEASED@ status, the operation shall be rejected with an @ErrorInfo@ with the @RoomIsReleased@ error code from the "chat-specific error codes":#error-codes.
 ** @(CHA-RL1d)@ @[Testable]@ If a room lifecycle operation is already in progress, this operation shall wait until the current operation completes before continuing, subject to @CHA-RL7@.
@@ -115,15 +115,15 @@ h4(#rooms-lifecycle-operations). Room Lifecycle Operations
 ** @(CHA-RL3a)@ @[Testable]@ If the room is already in the @RELEASED@ status, this operation is no-op.
 ** @(CHA-RL3b)@ @[Testable]@ If the room is in the @DETACHED@ status, then the room is immediately transitioned to @RELEASED@ and the operation succeeds.
 ** @(CHA-RL3i)@ @[Testable]@ If the room is in the @INITIALIZING@ status, then the room is immediately transitioned to @RELEASED@ and the operation succeeds.
-** @(CHA-RL3i)@ @[Testable]@ If the room is in the @INITIALIZED@ status, then the room is immediately transitioned to @RELEASED@ and the operation succeeds.
+** @(CHA-RL3j)@ @[Testable]@ If the room is in the @INITIALIZED@ status, then the room is immediately transitioned to @RELEASED@ and the operation succeeds.
 ** @(CHA-RL3c)@ @[Testable]@ If the room is in the @RELEASING@ status, then the operation will return the result of the pending @release@ operation, or throw any exception that it throws.
-** @(CHA-RL3c)@ @[Testable]@ When the release operation commences, the room will transition into the @RELEASING@ status any any transient disconnect timeouts shall be cleared.
+** @(CHA-RL3l)@ @[Testable]@ When the release operation commences, the room will transition into the @RELEASING@ status any any transient disconnect timeouts shall be cleared.
 ** @(CHA-RL3d)@ @[Testable]@ All features channels are detached in sequence.
 ** @(CHA-RL3e)@ @[Testable]@ If a channel is in the @FAILED@ state when it is time to detach, it shall be ignored.
 ** @(CHA-RL3f)@ @[Testable]@ If a channel fails to detach, the channel detach sequence will be retried after a short wait.
 ** @(CHA-RL3g)@ @[Testable]@ Once all channels have entered the @DETACHED@ state, then the room state is transitioned to @RELEASED@ and the operation completes.
 ** @(CHA-RL3h)@ @[Testable]@ Upon operation completion, the underlying Realtime Channels are released from the core SDK prevent leakage.
-** @(CHA-RL3i)@ @[Testable]@ If a room lifecycle operation is already in progress, this operation shall wait until the current operation completes before continuing, subject to @CHA-RL7@.
+** @(CHA-RL3k)@ @[Testable]@ If a room lifecycle operation is already in progress, this operation shall wait until the current operation completes before continuing, subject to @CHA-RL7@.
 * @(CHA-RL5)@ A room must @RETRY@ whenever it enters the @SUSPENDED@ state.
 ** @(CHA-RL5a)@ @[Testable]@ When entering a retry-loop, the room must first @DETACH@ all contributors underlying realtime channels.
 ** @(CHA-RL5b)@ @[Testable]@ If the operation above fails, then it must be retried after a short wait.
@@ -160,7 +160,7 @@ As well as user-initiated operations, the room must monitor its underlying resou
 *** @(CHA-RL4b5)@ @[Testable]@ If a channel lifecycle operation is not in progress and the channel state is @FAILED@, then the room status shall be transitioned to @FAILED@, using the @reason@ for the channel state change as the @error@ for the room status change. All @transient disconnect timeouts@ are cancelled and any non-detached contributors are detached.
 *** @(CHA-RL4b6)@ @[Testable]@ If a channel lifecycle operation is not in progress and the channel state is @ATTACHING@ and a transient disconnect timeout exists for the contributor, then no action is needed.
 *** @(CHA-RL4b7)@ @[Testable]@ If a channel lifecycle operation is not in progress and the channel state is @ATTACHING@ and no transient disconnect timeout exists for the contributor, then a timeout is created with a 5 second limit. Upon timeout, the room status is transitioned to @ATTACHING@, using the @reason@ from the initial channel state change as the error for the transition.
-*** @(CHA-RL4b7)@ @[Testable]@ If a channel lifecycle operation is not in progress and the channel state is @ATTACHED@ and a transient disconnect timeout exists for the contributor, the timeout is cleared.
+*** @(CHA-RL4b10)@ @[Testable]@ If a channel lifecycle operation is not in progress and the channel state is @ATTACHED@ and a transient disconnect timeout exists for the contributor, the timeout is cleared.
 *** @(CHA-RL4b8)@ @[Testable]@ If a channel lifecycle operation is not in progress, the channel state is @ATTACHED@, the room status is NOT @ATTACHED@ and all contibutors channel are now @ATTACHED@, the room status is transitioned to @ATTACHED@.
 *** @(CHA-RL4b9)@ @[Testable]@ If a channel lifecycle operation is not in progress and the channel state is @SUSPENDED@, then the room status is transitioned to @SUSPENDED@, using the @reason@ of the channel state change as the error. Any transient disconnect timeouts are cancelled and the room enters the @RETRY@ loop.
 
@@ -202,7 +202,7 @@ Broadly speaking, messages are published via REST calls to the Chat HTTP API and
 ** @(CHA-M4b)@ @[Testable]@ A subscription can de-registered from incoming messages. Removing a subscription has no side effects on the status of the room or the underlying realtime channel.
 ** @(CHA-M4c)@ @[Testable]@ When a realtime message with @name@ set to @message.created@ is received, it is translated into a message event, which contains a @type@ field with the event type as well as a @message@ field containing the "@Message Struct@":#chat-structs-message. This event is then broadcast to all subscribers.
 ** @(CHA-M4d)@ @[Testable]@ If a realtime message with an unknown @name@ is received, the SDK shall silently discard the message, though it may log at @DEBUG@ or @TRACE@ level.
-** @(CHA-M5d)@ @[Testable]@ Incoming realtime events that are malformed (unknown field should be ignored) shall not be emitted to subscribers.
+** @(CHA-M5k)@ @[Testable]@ Incoming realtime events that are malformed (unknown field should be ignored) shall not be emitted to subscribers.
 * @(CHA-M5)@ For a given subscription, messages prior to the point of subscription can be retrieved in a history-like request. Note that this is the point in the message flow @(subscription point)@ at which the subscription was made, NOT the channel attachment point.
 ** @(CHA-M5a)@ @[Testable]@ If a subscription is added when the underlying realtime channel is @ATTACHED@, then the @subscription point@ is the current @channelSerial@ of the realtime channel.
 ** @(CHA-M5b)@ @[Testable]@ If a subscription is added when the underlying realtime channel is in any other state, then its @subscription point@ becomes the @attachSerial@ at the the point of channel attachment.
@@ -263,7 +263,7 @@ Presence allows chat room users to indicate to others that they're online, as we
 ** @(CHA-PR3b)@ This specification item has been removed in favour of @CHA-PR3c - CHA-PR3g@.
 ** @(CHA-PR3c)@ If the room status is @Initialized@ or @Initializing@, behaviour depends on whether attach has been called.
 *** @(CHA-PR3c1)@ @[Testable]@ If the attach has been called, then the @enter@ call will wait for the attach operation to succeed and then call the underlying presence @enter@ operation. It will throw an error if the attach fails.
-*** @(CHA-PR3c1)@ @[Testable]@ If the attach has not been called, then the @enter@ call will throw an error.
+*** @(CHA-PR3c2)@ @[Testable]@ If the attach has not been called, then the @enter@ call will throw an error.
 ** @(CHA-PR3d)@ @[Testable]@ If the room status is @Attaching@, then the @enter@ call will wait for the attach operation to succeed and then call the underlying presence @enter@ operation. It will throw an error if the attach fails.
 ** @(CHA-PR3e)@ @[Testable]@ If the room status is @Attached@, then the @enter@ call will invoke the underlying @presence.enter()@ call.
 ** @(CHA-PR3f)@ @[Testable]@ If the room status is @Detached@, an @ErrorInfo@ with code 40000, explaining that attach must be called first, will be thrown.
@@ -273,7 +273,7 @@ Presence allows chat room users to indicate to others that they're online, as we
 ** @(CHA-PR10b)@ @[Testable]@ This specification item has been removed in favour of @CHA-PR10c - CHA-PR10g@.
 ** @(CHA-PR10c)@ If the room status is @Initialized@ or @Initializing@, behaviour depends on whether attach has been called.
 *** @(CHA-PR10c1)@ @[Testable]@ If the attach has been called, then the @update@ call will wait for the attach operation to succeed and then call the underlying presence @update@ operation. It will throw an error if the attach fails.
-*** @(CHA-PR10c1)@ @[Testable]@ If the attach has not been called, then the @update@ call will throw an error.
+*** @(CHA-PR10c2)@ @[Testable]@ If the attach has not been called, then the @update@ call will throw an error.
 ** @(CHA-PR10d)@ @[Testable]@ If the room status is @Attaching@, then the @update@ call will wait for the attach operation to succeed and then call the underlying presence @update@ operation. It will throw an error if the attach fails.
 ** @(CHA-PR10e)@ @[Testable]@ If the room status is @Attached@, then the @update@ call will invoke the underlying @presence.enter()@ call.
 ** @(CHA-PR10f)@ @[Testable]@ If the room status is @Detached@, an @ErrorInfo@ with code 40000, explaining that attach must be called first, will be thrown.
@@ -285,15 +285,15 @@ Presence allows chat room users to indicate to others that they're online, as we
 ** @(CHA-PR6a)@ @[Testable] This requirement has been removed in favour of @CHA-PR6b - CHA-PR6f@
 ** @(CHA-PR6b)@ If the room status is @Initialized@ or @Initializing@, behaviour depends on whether attach has been called.
 *** @(CHA-PR6b1)@ @[Testable]@ If the attach has been called, then the @get@ call will wait for the attach operation to succeed and then call the underlying presence @get@ operation. It will throw an error if the attach fails.
-*** @(CHA-PR6b1)@ @[Testable]@ If the attach has not been called, then the @get@ call will throw an error.
+*** @(CHA-PR6b2)@ @[Testable]@ If the attach has not been called, then the @get@ call will throw an error.
 ** @(CHA-PR6c)@ @[Testable]@ If the room status is @Attaching@, then the @get@ call will wait for the attach operation to succeed and then call the underlying presence @get@ operation. It will throw an error if the attach fails.
 ** @(CHA-PR6d)@ @[Testable]@ If the room status is @Attached@, then the @get@ call will invoke the underlying @presence.enter()@ call.
 ** @(CHA-PR6e)@ @[Testable]@ If the room status is @Detached@, an @ErrorInfo@ with code 40000, explaining that attach must be called first, will be thrown.
 ** @(CHA-PR6f)@ @[Testable]@ For any other room status, an @ErrorInfo@ with code 40000 will be thrown.
 * @(CHA-PR7)@ Users may subscribe to presence events.
 ** @(CHA-PR7a)@ @[Testable]@ Users may provide a listener to subscribe to all "presence events":#chat-structs-presence-event in a room.
 ** @(CHA-PR7b)@ @[Testable]@ Users may provide a listener and a list of selected "presence events":#chat-structs-presence-event, to subscribe to just those events in a room.
-** @(CHA-PR7b)@ @[Testable]@ A subscription to presence may be removed, after which it shall receive no further events.
+** @(CHA-PR7c)@ @[Testable]@ A subscription to presence may be removed, after which it shall receive no further events.
 * @(CHA-PR8)@ @[Testable]@ Users may subscribe to discontinuity events to know when there's been a break in presence. Their listener will be called when a discontinuity event is triggered from the room lifecycle. For presence, there shouldn't need to be user action as the underlying core SDK will heal the presence set.
 * @(CHA-PR9)@ Users may configure their presence options via the @RoomOptions@ provided at room configuration time.
 ** @(CHA-PR9a)@ @[Testable]@ Setting @enter@ to false prevents the user from entering presence by means of the @ChannelMode@ on the underlying realtime channel. Entering presence will result in an error. The default is true.
@@ -309,7 +309,7 @@ Typing Indicators allow chat room users to indicate to others that they are typi
 * @(CHA-T2)@ @[Testable]@ Users may retrieve a list of the currently typing client IDs. The behaviour depends on the current room status, as presence operations in a Realtime Client cause implicit attaches.
 ** @(CHA-T2b)@ If the room status is @Initialized@ or @Initializing@, behaviour depends on whether attach has been called.
 *** @(CHA-T2b1)@ @[Testable]@ If the attach has been called, then the @get@ call will wait for the attach operation to succeed and then call the underlying presence @get@ operation. It will throw an error if the attach fails.
-*** @(CHA-T2b1)@ @[Testable]@ If the attach has not been called, then the @get@ call will throw an error.
+*** @(CHA-T2b2)@ @[Testable]@ If the attach has not been called, then the @get@ call will throw an error.
 ** @(CHA-T2c)@ @[Testable]@ If the room status is @Attaching@, then the @get@ call will wait for the attach operation to succeed and then call the underlying presence @get@ operation. It will throw an error if the attach fails.
 ** @(CHA-T2d)@ @[Testable]@ If the room status is @Attached@, then the @get@ call will invoke the underlying @presence.enter()@ call.
 ** @(CHA-T2e)@ @[Testable]@ If the room status is @Detached@, an @ErrorInfo@ with code 40000, explaining that attach must be called first, will be thrown.