test: wait for the presence sync before the RTP8 lifecycle enters

[owenpearson]

test/uts/realtime/integration/presence_lifecycle_test.py::test_rtp8_enter_update_leave_lifecycle
fails intermittently in CI with assert 1 == 2: client B's first presence event is PRESENT
rather than ENTER. It failed six times between 2026-10-01 and 2026-10-08, on 3.10 to 3.14,
on main-based branches and on integration/v4.

The sandbox answers the first attach to a new channel with HAS_PRESENCE, even though the
channel is empty, and follows it with a SYNC about 80ms later. When client A's enter reaches
the server inside that window, the SYNC carries the member to client B as PRESENT, just
ahead of the live ENTER:

0.1144  B  ATTACHED  flags 3080257  (HAS_PRESENCE)
0.1714  A  sends its enter
0.2046  B  SYNC      [PRESENT lifecycle-client  id NBCSu-EAvn:0:0]
0.2047  B  PRESENCE  [ENTER   lifecycle-client  id NBCSu-EAvn:0:0]

The ENTER carries the same id and is discarded as a duplicate, as ably-js discards it, so
the SDK is behaving correctly. The specification's steps go straight from client B's attach
to client A's enter without waiting for client B's sync, and ably-js's derived test makes
the same assumption. Filed as ably/specification#564.

The test now waits for client B's sync with presence.get() (RTP11c1) before client A
attaches, under a # UTS SPEC ERROR: comment, and keeps every assertion. The legacy suite's
await_presence_sync() in test/ably/realtime/realtimepresence_test.py does the same for
the same reason. deviations.md records the fault among the realtime/integration spec
errors.

Verification

Every channel ProtocolMessage both clients received was recorded while client A's enter
was sent a fixed delay after client B's ATTACHED, swept from 50 to 105ms, three passes per
delay under each protocol:

	runs	first event PRESENT
without the wait	336	28, all between 50 and 84ms, json and msgpack alike
with the wait	336	0

Without a delay it did not fail in 72 local runs, because local latency puts the enter
ahead of the SYNC. The test file passes 15 runs in a row under both protocols, and
ruff check is clean.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes
  • Reduced timing-related flakiness in the realtime presence lifecycle test by waiting for the initial presence sync before checking subsequent events.
• Documentation
  • Updated the UTS specification deviations record to document the presence event ordering issue and its upstream fixture race.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: b0846907-39ee-475f-820e-4c5cb26d52c0

---

📥 Commits

Reviewing files that changed from the base of the PR and between e195b3c and d15c566.

---

📒 Files selected for processing (2)

• test/uts/deviations.md
• test/uts/realtime/integration/presence_lifecycle_test.py

---

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.

---

---

Walkthrough

The realtime presence lifecycle test now waits for client B’s initial presence sync before client A attaches. The deviations record adds the race as issue #564 and updates the specification-error count.

Changes

Presence lifecycle test

Layer / File(s)	Summary
Add presence sync wait test/uts/realtime/integration/presence_lifecycle_test.py, test/uts/deviations.md	Client B calls presence.get() after subscribing and before client A attaches. The deviations record describes the possible PRESENT-before-ENTER event order and records issue #564.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~8 minutes

Change: Other

Merge Risk: ⚪ Minimal · up to d15c5

The test now waits for client B’s initial presence sync before client A attaches, preventing the documented PRESENT-before-ENTER ordering race. No actionable merge-blocking risk remains.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage		Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 1 files. (1 skipped: 1 …	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title clearly and concisely describes the main change: waiting for the presence sync before the RTP8 lifecycle test proceeds.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

---

Full details: Docstring Coverage

Explanation

Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 1 files. (1 skipped: 1 unsupported.)

---

---

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Commit to this branch
• Create a new PR

---

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

---

---

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

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

• X
• Mastodon
• Reddit
• LinkedIn

---

_{I’m a rabbit, ears held high,
I wait for presence to sync nearby.
Client B checks before Client A,
So events arrive in a steadier way.
Issue five-six-four is noted in the den.}

_{Comment @coderabbitai help to get the list of available commands.}