harden reconnect behaviour

[lukasIO]

Before you submit your PR

Make sure the following is true before submitting your PR:

• I have read the contributing guidelines and validated that this PR will be accepted.
• I have read and followed the principles regarding breaking changes, testing, and code quality.

PR description

Describe the changes in this PR. Explain what the PR is meant to solve and how to reproduce the issue in the first place.

Breaking changes

If this PR introduces breaking changes, list them here and document the rationale for introducing such a change.

MSRV

If the PR modifies the crate's MSRV (Minimum Supported Rust Version), document it here.

Testing

Ideally, unit test the code you add, but ensure you're not repeating existing test cases. Use as many already written scaffolding, utilities as possible; write your own, when needed. If external services, APIs, tokens are required (e.g., running an LK server instance), provide the necessary information. Make sure your tests perform useful, context-aware assertions and do not simply emulate "happy paths".

Async

We want the project to be runtime-agnostic, so please reuse what's already in livekit-runtime and feel free to add anything missing. It's ok to use Tokio directly, when writing unit tests, if necessary. When testing, do not use artificial delays for the state to "catch up"; instead, respect the event flow and subscribe properly using channels or other mechanisms.

[github-actions]

Changeset

The following package versions will be affected by this PR:

Package	Bump
livekit	patch
livekit-api	patch
livekit-ffi	patch
livekit-uniffi	patch

[ladvoc]

issue: If the room is explicitly closed by the user, this task will not be properly cancelled. The addition of this select! brought my attention here, but this is a pre-existing issue.

You will find there is a close_notifier referenced on L805 with a comment mentioning it needs to be used as a signal to cancel this task—however, this was wired up. Solution is to wire this up and use it as a branch in your select! in order to be able to break out of the loop early when the room is closed.

[lukasIO]

great catch!

addressed in e3320d3

[lukasIO]

wanted to call this out specifically. It's "just" a spec generated by https://github.com/juxt/allium, but in case someone is opposed to adding this in, let me know

[ladvoc]

My only concern is whether any parts of the spec could be misleading to an agent reading it in the future. In those cases, relying on the code as the source of truth might help avoid confusion. That said, I don’t feel strongly about it.

[lukasIO]

that's a fair concern. I think it's minimised as much as possible by having a special (allium specific) extension and allium itself regularly compares spec against code.

[stephen-derosa]

is there any world where we'd want to apply this reconnet behavior to initial connection? Im thinking of an application facing the same sort of network instability that may cause a reconnect on initial connection.

[ladvoc]

LGTM ✅

[lukasIO]

is there any world where we'd want to apply this reconnet behavior to initial connection? Im thinking of an application facing the same sort of network instability that may cause a reconnect on initial connection.

we currently differentiate between initial connection and reconnection, but we still allow for re-trying on the initial connection (which would effectively be a "reconnect" just for a connection that had never been established in the first place), see

rust-sdks/livekit/src/rtc_engine/mod.rs

Lines 502 to 503 in 129e503

	for i in 0..(max_retries + 1) {
	match try_connect().await {