[ECO-5337] Implement the subscriptions spec #27

lawrence-forooghian · 2025-07-16T11:54:22Z

Note: This PR is based on top of #26; please review that one first.

Implements ably/specification#346. See commit messages for more details.

Summary by CodeRabbit

New Features
- Subscription APIs now provide subscription handles to callbacks, enabling listeners to deregister themselves.
- Callbacks for updates and events are executed on a user-specified dispatch queue for greater control.
- Added ability to emit updates externally on user callback queues for live maps and counters.
- Introduced reset functionality for root objects on channel attachment indicating empty state.
Bug Fixes
- Improved error propagation and handling in subscription and event registration methods.
- Update emission is deferred appropriately during synchronization, ensuring subscribers receive updates in the correct order.
- Clarified behavior on channel attachment to preserve root object instance while clearing data.
Documentation
- Contributing guidelines updated with best practices for callback type usage and error handling.
Tests
- Expanded test coverage for subscription, unsubscription, and update emission behaviors.
- Tests now verify correct update notifications, error handling, and no-op emissions for unsupported operations.
- Updated tests to consistently use main dispatch queue for callbacks and to await async update emissions.
Style
- Callback typealiases and method signatures updated for clarity and consistency across the API.

It's a bit annoying that Xcode's autocomplete didn't do this when I created these implementations.

Missed this in ce8c022.

Didn't do this in ce8c022 because I didn't have a good idea of our threading approach. But for the initial approach that we'll be taking — namely, calling the callbacks on ably-cocoa's callback queue — I think we'll need it. Haven't done it for batch stuff yet because I don't yet know whether it'll be necessary (will get a better idea when we implement it). Now that the callback can be called on any thread, we can no longer easily use the "capture the return value of `subscribe` pattern so that we can unsubscribe later" pattern. So, I've decided to pass the subscripiton as a second argument to the callback. Might be there's a better pattern we can use (e.g. pass in an object to the `subscribe` call, like JS `fetch`'s AbortController), but this'll do for now.

The correct behaviour wasn't clear from the spec when I wrote cb427d8, but new spec PR [1] makes it seem that this is the right thing to do (still needs clarifying though). [1] ably/specification#346

Mistake in 6430358.

This is preparation for implementing subscriptions. Cursor updated the tests.

Motivation as in 3f6de86; the new spec points in [1] tell us these can throw. [1] ably/specification#346

umair-ably · 2025-07-29T08:53:15Z

@coderabbitai full review

coderabbitai · 2025-07-29T08:53:21Z

✅ Actions performed

Full review triggered.

coderabbitai · 2025-07-29T08:53:24Z

Walkthrough

This update introduces a comprehensive overhaul of the LiveObjects subscription API. It adds new generic update types, explicit callback queue management, and subscription handles to the listener APIs. Internal classes and tests are updated to support these changes, including new mechanisms for emitting updates, managing subscriptions, and propagating errors. Test coverage is expanded to verify subscription, emission, and unsubscription behaviors.

Changes

Cohort / File(s)	Change Summary
Public API: Subscription Callbacks and Types `Sources/AblyLiveObjects/Public/PublicTypes.swift`, `Sources/AblyLiveObjects/Public/Public Proxy Objects/PublicDefaultLiveCounter.swift`, `Sources/AblyLiveObjects/Public/Public Proxy Objects/PublicDefaultLiveMap.swift`, `Sources/AblyLiveObjects/Public/Public Proxy Objects/PublicDefaultRealtimeObjects.swift`	Refactored callback typealiases to include subscription handles, marked as `@Sendable`, and made callbacks escaping. Updated `subscribe` and `on` methods to accept new callback signatures, propagate errors, and forward extra parameters as needed.
Internal: Subscription, Emission, and Update Flow `Sources/AblyLiveObjects/Internal/LiveObjectMutableState.swift`, `Sources/AblyLiveObjects/Internal/LiveObjectUpdate.swift`, `Sources/AblyLiveObjects/Internal/InternalDefaultLiveCounter.swift`, `Sources/AblyLiveObjects/Internal/InternalDefaultLiveMap.swift`, `Sources/AblyLiveObjects/Internal/InternalDefaultRealtimeObjects.swift`, `Sources/AblyLiveObjects/Internal/DefaultLiveCounterUpdate.swift`, `Sources/AblyLiveObjects/Internal/DefaultLiveMapUpdate.swift`, `Sources/AblyLiveObjects/Internal/DefaultInternalPlugin.swift`, `Sources/AblyLiveObjects/Internal/ObjectsPool.swift`	Introduced generic `LiveObjectUpdate` enum. Overhauled subscription management with explicit subscribe/unsubscribe flows, subscription tracking, and update emission on user-specified queues. Updated all relevant methods to propagate callback queues and update types. Added deferred update emission and reset logic for object pools.
Utility Extension `Sources/AblyLiveObjects/Utility/NSLock+Extensions.swift`	Added an extension for typed-throwing lock execution to support error propagation in locked contexts.
Documentation `CONTRIBUTING.md`	Updated contributing guidelines for callback type usage and error handling in methods that do not support typed throws.
Tests: Subscription, Emission, and Update Verification `Tests/AblyLiveObjectsTests/Helpers/Subscriber.swift`, `Tests/AblyLiveObjectsTests/InternalDefaultLiveCounterTests.swift`, `Tests/AblyLiveObjectsTests/InternalDefaultLiveMapTests.swift`, `Tests/AblyLiveObjectsTests/LiveObjectMutableStateTests.swift`, `Tests/AblyLiveObjectsTests/ObjectsPoolTests.swift`, `Tests/AblyLiveObjectsTests/InternalDefaultRealtimeObjectsTests.swift`, `Tests/AblyLiveObjectsTests/JS Integration Tests/ObjectsIntegrationTests.swift`	Added or updated test helpers for subscription tracking. Refactored tests to use explicit callback queues, capture and assert update values, and verify emission/unsubscription flows. Converted relevant tests to async and expanded coverage for edge cases and error propagation.

Sequence Diagram(s)

sequenceDiagram
    participant User as User Code
    participant PublicObj as Public LiveObject
    participant InternalObj as Internal LiveObject
    participant State as LiveObjectMutableState
    participant Queue as userCallbackQueue

    User->>PublicObj: subscribe(listener)
    PublicObj->>InternalObj: subscribe(listener, coreSDK)
    InternalObj->>State: subscribe(listener, coreSDK, updateSelfLater)
    State-->>InternalObj: SubscribeResponse
    InternalObj-->>PublicObj: SubscribeResponse
    PublicObj-->>User: SubscribeResponse

    Note over State: When update occurs
    InternalObj->>State: emit(update, on: userCallbackQueue)
    State->>Queue: dispatch listener(update, subscription)
    Queue-->>User: listener(update, subscription)

Estimated code review effort

🎯 5 (Critical) | ⏱️ ~75 minutes

Assessment against linked issues

Objective	Addressed	Explanation
LiveObjects subscription API overhaul (ECO-5337)	✅
Subscription callbacks provide subscription handles for deregistration (ECO-5337)	✅
Callbacks are invoked on user-specified queues (ECO-5337)	✅
Subscription/unsubscription and emission flows are tested (ECO-5337)	✅

Assessment against linked issues: Out-of-scope changes

Code Change	Explanation
Update to contributing guidelines for callback type usage and error handling (`CONTRIBUTING.md`)	Documentation changes are not directly part of the subscription API implementation but provide helpful context; still, they do not alter functional code.
Addition of `ablyLiveObjects_withLockWithTypedThrow` to `NSLock+Extensions.swift`	This utility supports error propagation in locked contexts, which is adjacent to but not strictly required for the subscription API objective. However, it does not introduce unrelated functionality.

Suggested reviewers

maratal
umair-ably

Poem

In fields of code where objects thrive,
Subscriptions now can leap and dive.
With queues and handles, swift and bright,
Updates hop in orderly delight.
Rabbits cheer, for bugs take flight—
Review this patch, and all feels right!
🐇✨

Note

⚡️ Unit Test Generation is now available in beta!

Learn more here, or try it out under "Finishing Touches" below.

✨ Finishing Touches

📝 Generate Docstrings

🧪 Generate unit tests

Create PR with unit tests
Post copyable unit tests in a comment
Commit unit tests in branch ECO-5337-subscriptions

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

Review comments: Directly reply to a review comment made by CodeRabbit. Example:
- I pushed a fix in commit <commit_id>, please review it.
- Explain this complex logic.
- Open a follow-up GitHub issue for this discussion.
Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
- @coderabbitai explain this code block.
- @coderabbitai modularize this function.
PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
- @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
- @coderabbitai read src/utils.ts and explain its main purpose.
- @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
- @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

@coderabbitai pause to pause the reviews on a PR.
@coderabbitai resume to resume the paused reviews.
@coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
@coderabbitai full review to do a full review from scratch and review all the files again.
@coderabbitai summary to regenerate the summary of the PR.
@coderabbitai generate docstrings to generate docstrings for this PR.
@coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
@coderabbitai generate unit tests to generate unit tests for this PR.
@coderabbitai resolve resolve all the CodeRabbit review comments.
@coderabbitai configuration to show the current CodeRabbit configuration for the repository.
@coderabbitai help to get help.

Other keywords and placeholders

Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (`.coderabbit.yaml`)

You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
Please see the configuration documentation for more information.
If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

Visit our Documentation for detailed information on how to use CodeRabbit.
Join our Discord Community to get help, request features, and share feedback.
Follow us on X/Twitter for updates and announcements.

coderabbitai

Actionable comments posted: 1

🔭 Outside diff range comments (1)

Tests/AblyLiveObjectsTests/InternalDefaultRealtimeObjectsTests.swift (1)

341-401: Clarify root reset behavior: clear data only, do not replace instance

The enhancements to handlesHasObjectsFalse are solid, but the lingering TODO about whether to replace or clear the root object can now be resolved. By convention (and as seen in common object-pool patterns), a “reset”/“clear” operation should empty the root’s data without re-instantiating the pool/root object itself.

Actions:

Remove the TODO at line 398.

Update the comment to state clearly: “Per spec and common practice, clearing the pool should preserve the root instance and only clear its data.”

🧹 Nitpick comments (1)

Sources/AblyLiveObjects/Internal/InternalDefaultLiveMap.swift (1)
417-431: Consider simplifying the update merging logic.

The current implementation uses uniqueKeysWithValues with a comment expressing concern about this approach. Since the keys come from iterating over map entries, they should indeed be unique by definition. Consider using a simpler approach:
let update = filteredPerKeyUpdates.reduce(into: [:]) { result, element in
    result.merge(element.update) { _, new in new }
}
This would make the uniqueness guarantee more explicit and avoid the need for uniqueKeysWithValues.

CONTRIBUTING.md

Based on [1] at 2963300. Have not implemented RTL04b1's channel mode checking for same reason as mentioned in 8d881e2. Have not currently tested `replaceData`'s return value; will do once [2] clarified. [1] ably/specification#346 [2] https://github.com/ably/specification/pull/346/files#r2201363446

coderabbitai

Actionable comments posted: 0

🧹 Nitpick comments (1)

Sources/AblyLiveObjects/Internal/InternalDefaultLiveMap.swift (1)

417-431: Consider simplifying the update aggregation logic.

The current implementation is overly complex for merging non-overlapping key updates. Since each key operation produces a unique key, the concern about overlapping keys shouldn't exist.

Simplify the update aggregation:

-// RTLM17c: Merge the updates, skipping no-ops
-// I don't love having to use uniqueKeysWithValues, when I shouldn't have to. I should be able to reason _statically_ that there are no overlapping keys. The problem that we're trying to use LiveMapUpdate throughout instead of something more communicative. But I don't know what's to come in the spec so I don't want to mess with this internal interface.
-let filteredPerKeyUpdates = perKeyUpdates.compactMap { update -> LiveMapUpdate? in
-    switch update {
-    case .noop:
-        nil
-    case let .update(update):
-        update
-    }
-}
-let filteredPerKeyUpdateKeyValuePairs = filteredPerKeyUpdates.reduce(into: []) { result, element in
-    result.append(contentsOf: Array(element.update))
-}
-let update = Dictionary(uniqueKeysWithValues: filteredPerKeyUpdateKeyValuePairs)
-return .update(DefaultLiveMapUpdate(update: update))
+// RTLM17c: Merge the updates, skipping no-ops
+var updates: [String: DefaultLiveMapUpdate.UpdateType] = [:]
+for perKeyUpdate in perKeyUpdates {
+    if case let .update(mapUpdate) = perKeyUpdate {
+        updates.merge(mapUpdate.update) { _, new in new }
+    }
+}
+return updates.isEmpty ? .noop : .update(DefaultLiveMapUpdate(update: updates))

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1434bbb and 392fae3.

📒 Files selected for processing (18)

CONTRIBUTING.md (1 hunks)
Sources/AblyLiveObjects/Internal/DefaultLiveCounterUpdate.swift (1 hunks)
Sources/AblyLiveObjects/Internal/DefaultLiveMapUpdate.swift (1 hunks)
Sources/AblyLiveObjects/Internal/InternalDefaultLiveCounter.swift (9 hunks)
Sources/AblyLiveObjects/Internal/InternalDefaultLiveMap.swift (17 hunks)
Sources/AblyLiveObjects/Internal/InternalDefaultRealtimeObjects.swift (14 hunks)
Sources/AblyLiveObjects/Internal/LiveObjectMutableState.swift (2 hunks)
Sources/AblyLiveObjects/Internal/LiveObjectUpdate.swift (1 hunks)
Sources/AblyLiveObjects/Internal/ObjectsPool.swift (8 hunks)
Sources/AblyLiveObjects/Public/Public Proxy Objects/PublicDefaultLiveCounter.swift (1 hunks)
Sources/AblyLiveObjects/Public/Public Proxy Objects/PublicDefaultLiveMap.swift (1 hunks)
Sources/AblyLiveObjects/Utility/NSLock+Extensions.swift (1 hunks)
Tests/AblyLiveObjectsTests/Helpers/Subscriber.swift (1 hunks)
Tests/AblyLiveObjectsTests/InternalDefaultLiveCounterTests.swift (14 hunks)
Tests/AblyLiveObjectsTests/InternalDefaultLiveMapTests.swift (44 hunks)
Tests/AblyLiveObjectsTests/InternalDefaultRealtimeObjectsTests.swift (5 hunks)
Tests/AblyLiveObjectsTests/LiveObjectMutableStateTests.swift (3 hunks)
Tests/AblyLiveObjectsTests/ObjectsPoolTests.swift (15 hunks)

🚧 Files skipped from review as they are similar to previous changes (11)

Tests/AblyLiveObjectsTests/InternalDefaultRealtimeObjectsTests.swift
Sources/AblyLiveObjects/Internal/InternalDefaultRealtimeObjects.swift
Sources/AblyLiveObjects/Internal/DefaultLiveMapUpdate.swift
Sources/AblyLiveObjects/Internal/DefaultLiveCounterUpdate.swift
Sources/AblyLiveObjects/Utility/NSLock+Extensions.swift
CONTRIBUTING.md
Sources/AblyLiveObjects/Public/Public Proxy Objects/PublicDefaultLiveCounter.swift
Tests/AblyLiveObjectsTests/Helpers/Subscriber.swift
Sources/AblyLiveObjects/Internal/LiveObjectUpdate.swift
Sources/AblyLiveObjects/Public/Public Proxy Objects/PublicDefaultLiveMap.swift
Tests/AblyLiveObjectsTests/InternalDefaultLiveMapTests.swift

🧰 Additional context used

📓 Path-based instructions (3)

**/!(*Test|*Tests).swift

📄 CodeRabbit Inference Engine (.cursor/rules/swift.mdc)

**/!(*Test|*Tests).swift: Satisfy SwiftLint's explicit_acl rule: all declarations should specify Access Control Level keywords explicitly.
When writing an extension of a type, favour placing the access level on the declaration of the extension rather than each of its individual members.

Files:

Sources/AblyLiveObjects/Internal/LiveObjectMutableState.swift
Sources/AblyLiveObjects/Internal/InternalDefaultLiveCounter.swift
Sources/AblyLiveObjects/Internal/ObjectsPool.swift
Sources/AblyLiveObjects/Internal/InternalDefaultLiveMap.swift

**/*.swift

📄 CodeRabbit Inference Engine (.cursor/rules/swift.mdc)

**/*.swift: When writing initializer expressions, when the type that is being initialized can be inferred, favour using the implicit .init(…) form instead of explicitly writing the type name.
When writing enum value expressions, when the type that is being initialized can be inferred, favour using the implicit .caseName form instead of explicitly writing the type name.
When writing JSONValue or WireValue types, favour using the literal syntax enabled by their conformance to the ExpressibleBy*Literal protocols where possible.
When writing an array literal that starts with an initializer expression, start the initializer expression on the line after the opening square bracket of the array literal.

Files:

Sources/AblyLiveObjects/Internal/LiveObjectMutableState.swift
Tests/AblyLiveObjectsTests/ObjectsPoolTests.swift
Tests/AblyLiveObjectsTests/InternalDefaultLiveCounterTests.swift
Sources/AblyLiveObjects/Internal/InternalDefaultLiveCounter.swift
Sources/AblyLiveObjects/Internal/ObjectsPool.swift
Sources/AblyLiveObjects/Internal/InternalDefaultLiveMap.swift
Tests/AblyLiveObjectsTests/LiveObjectMutableStateTests.swift

**/Tests/**/*.swift

📄 CodeRabbit Inference Engine (.cursor/rules/testing.mdc)

**/Tests/**/*.swift: Use the Swift Testing framework (import Testing), not XCTest.
Do not use fatalError in response to a test expectation failure. Favour the usage of Swift Testing's #require macro.
Only add labels to test cases or suites when the label is different to the name of the suite struct or test method.
Follow the guidelines given under 'Attributing tests to a spec point' in the file CONTRIBUTING.md in order to tag the unit tests with the relevant specification points. Make sure to follow the exact format of the comments as described in that file. Pay particular attention to the difference between the meaning of @spec and @specPartial and be sure not to write @spec multiple times for the same specification point.
Add comments that explain when some piece of test data is not important for the scenario being tested.
When you need to import the following modules in the tests, do so in the following way: Ably: use import Ably; AblyLiveObjects: use @testable import AblyLiveObjects; AblyPlugin: use import AblyPlugin; do not do internal import.
When you need to pass a logger to internal components in the tests, pass TestLogger().
When you need to unwrap an optional value in the tests, favour using #require instead of guard let.
When creating testsOnly_ property declarations, do not write generic comments of the form 'Test-only access to the private createOperationIsMerged property'; the meaning of these properties is already well understood.

Files:

Tests/AblyLiveObjectsTests/ObjectsPoolTests.swift
Tests/AblyLiveObjectsTests/InternalDefaultLiveCounterTests.swift
Tests/AblyLiveObjectsTests/LiveObjectMutableStateTests.swift

🧠 Learnings (8)

📓 Common learnings

Learnt from: CR
PR: ably/ably-cocoa-liveobjects-plugin#0
File: .cursor/rules/specification.mdc:0-0
Timestamp: 2025-07-29T08:07:37.861Z
Learning: The LiveObjects functionality is referred to in the Specification simply as 'Objects'.

Sources/AblyLiveObjects/Internal/LiveObjectMutableState.swift (5)

Learnt from: CR
PR: ably/ably-cocoa-liveobjects-plugin#0
File: .cursor/rules/swift.mdc:0-0
Timestamp: 2025-07-29T08:07:47.875Z
Learning: Applies to AblyLiveObjects/**/!(*Test|*Tests).swift : When importing the Ably module inside the AblyLiveObjects library code (non-test code), use import Ably.

Learnt from: CR
PR: ably/ably-cocoa-liveobjects-plugin#0
File: .cursor/rules/swift.mdc:0-0
Timestamp: 2025-07-29T08:07:47.875Z
Learning: Applies to AblyLiveObjects/**/!(*Test|*Tests).swift : When importing the AblyPlugin module inside the AblyLiveObjects library code (non-test code), use internal import AblyPlugin.

Learnt from: CR
PR: ably/ably-cocoa-liveobjects-plugin#0
File: .cursor/rules/specification.mdc:0-0
Timestamp: 2025-07-29T08:07:37.861Z
Learning: The LiveObjects functionality is referred to in the Specification simply as 'Objects'.

Learnt from: CR
PR: ably/ably-cocoa-liveobjects-plugin#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-07-29T08:08:00.588Z
Learning: Applies to /Tests//*.swift : When you need to import the following modules in the tests, do so in the following way: Ably: use import Ably; AblyLiveObjects: use @testable import AblyLiveObjects; AblyPlugin: use import AblyPlugin; do not do internal import.

Learnt from: CR
PR: ably/ably-cocoa-liveobjects-plugin#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-07-29T08:07:58.385Z
Learning: Applies to /Tests//*.swift : When you need to import the following modules in the tests, do so in the following way: Ably: use import Ably; AblyLiveObjects: use @testable import AblyLiveObjects; AblyPlugin: use import AblyPlugin; do not do internal import.

Tests/AblyLiveObjectsTests/ObjectsPoolTests.swift (14)

Learnt from: CR
PR: ably/ably-cocoa-liveobjects-plugin#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-07-29T08:08:00.588Z
Learning: Applies to /Tests//*.swift : When you need to import the following modules in the tests, do so in the following way: Ably: use import Ably; AblyLiveObjects: use @testable import AblyLiveObjects; AblyPlugin: use import AblyPlugin; do not do internal import.

Learnt from: CR
PR: ably/ably-cocoa-liveobjects-plugin#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-07-29T08:07:58.385Z
Learning: Applies to /Tests//*.swift : When you need to import the following modules in the tests, do so in the following way: Ably: use import Ably; AblyLiveObjects: use @testable import AblyLiveObjects; AblyPlugin: use import AblyPlugin; do not do internal import.

Learnt from: CR
PR: ably/ably-cocoa-liveobjects-plugin#0
File: .cursor/rules/swift.mdc:0-0
Timestamp: 2025-07-29T08:07:47.875Z
Learning: Applies to AblyLiveObjects/**/!(*Test|*Tests).swift : When importing the Ably module inside the AblyLiveObjects library code (non-test code), use import Ably.

Learnt from: CR
PR: ably/ably-cocoa-liveobjects-plugin#0
File: .cursor/rules/swift.mdc:0-0
Timestamp: 2025-07-29T08:07:47.875Z
Learning: Applies to AblyLiveObjects/**/!(*Test|*Tests).swift : When importing the AblyPlugin module inside the AblyLiveObjects library code (non-test code), use internal import AblyPlugin.

Learnt from: CR
PR: ably/ably-cocoa-liveobjects-plugin#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-07-29T08:08:00.588Z
Learning: Applies to /Tests//*.swift : When creating testsOnly_ property declarations, do not write generic comments of the form 'Test-only access to the private createOperationIsMerged property'; the meaning of these properties is already well understood.

Learnt from: CR
PR: ably/ably-cocoa-liveobjects-plugin#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-07-29T08:07:58.385Z
Learning: Applies to /Tests//*.swift : When creating testsOnly_ property declarations, do not write generic comments of the form 'Test-only access to the private createOperationIsMerged property'; the meaning of these properties is already well understood.

Learnt from: CR
PR: ably/ably-cocoa-liveobjects-plugin#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-07-29T08:08:00.588Z
Learning: Applies to /Tests//*.swift : Follow the guidelines given under 'Attributing tests to a spec point' in the file CONTRIBUTING.md in order to tag the unit tests with the relevant specification points. Make sure to follow the exact format of the comments as described in that file. Pay particular attention to the difference between the meaning of @spec and @specPartial and be sure not to write @spec multiple times for the same specification point.

Learnt from: CR
PR: ably/ably-cocoa-liveobjects-plugin#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-07-29T08:07:58.385Z
Learning: Applies to /Tests//*.swift : When writing tests, make sure to add comments that explain when some piece of test data is not important for the scenario being tested.

Learnt from: CR
PR: ably/ably-cocoa-liveobjects-plugin#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-07-29T08:07:58.385Z
Learning: Applies to /Tests//*.swift : When writing tests, follow the guidelines given under 'Attributing tests to a spec point' in the file CONTRIBUTING.md in order to tag the unit tests with the relevant specification points. Make sure to follow the exact format of the comments as described in that file. Pay particular attention to the difference between the meaning of @spec and @specPartial and be sure not to write @spec multiple times for the same specification point.

Learnt from: CR
PR: ably/ably-cocoa-liveobjects-plugin#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-07-29T08:08:00.588Z
Learning: Applies to /Tests//*.swift : Add comments that explain when some piece of test data is not important for the scenario being tested.

Learnt from: CR
PR: ably/ably-cocoa-liveobjects-plugin#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-07-29T08:07:58.385Z
Learning: Applies to /Tests//*.swift : When you need to pass a logger to internal components in the tests, pass TestLogger().

Learnt from: CR
PR: ably/ably-cocoa-liveobjects-plugin#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-07-29T08:08:00.588Z
Learning: Applies to /Tests//*.swift : When you need to pass a logger to internal components in the tests, pass TestLogger().

Learnt from: CR
PR: ably/ably-cocoa-liveobjects-plugin#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-07-29T08:08:00.588Z
Learning: Applies to /Tests//*.swift : Do not use fatalError in response to a test expectation failure. Favour the usage of Swift Testing's #require macro.

Learnt from: CR
PR: ably/ably-cocoa-liveobjects-plugin#0
File: .cursor/rules/testing.mdc:0-0
Timestamp: 2025-07-29T08:07:58.385Z
Learning: Applies to /Tests//*.swift : Do not use fatalError in response to a test expectation failure. Favour the usage of Swift Testing's #require macro.

Tests/AblyLiveObjectsTests/InternalDefaultLiveCounterTests.swift (15)