Skip to content

Sync UTS specs with 6.1.0 server-side resumability#511

Open
SimonWoolf wants to merge 1 commit into
mainfrom
uts-6.1.0-server-resumability
Open

Sync UTS specs with 6.1.0 server-side resumability#511
SimonWoolf wants to merge 1 commit into
mainfrom
uts-6.1.0-server-resumability

Conversation

@SimonWoolf

Copy link
Copy Markdown
Member

Spec PR #488 ("Move resumability decisions from the client to the server") updated features.md and api-docstrings.md but did not update the UTS test-spec sources or address createRecoveryKey's behaviour in SUSPENDED. This brings both in line.

features.md:

  • RTN16g2 is replaced by RTN16g3: createRecoveryKey() no longer returns Null in SUSPENDED. Since the client now retains its connectionKey and always attempts to resume (RTN14h), the connection remains recoverable while suspended. (RTN16g2 as written still listed SUSPENDED, which contradicts RTN8d/RTN9d retaining the key.)

UTS sources:

  • connection_id_key: RTN8c/RTN9c "id/key null in SUSPENDED" -> RTN8d/RTN9d "id/key retained in SUSPENDED" (connect first, then suspend).
  • connection_failures: RTN15g "no resume after connectionStateTtl" -> RTN14h "still attempts resume after the TTL", asserting every post-suspension reconnect carries resume=.
  • connection_recovery: RTN16g2 -> RTN16g3; the SUSPENDED case now expects a non-null recovery key.
  • channel_properties: RTL15b1 "channelSerial cleared on suspended" -> RTL15b2 "retained in suspended"; detach/failed cases relabelled.
  • channel_attach: RTL4j "ATTACH_RESUME set on reattach" -> "not set".
  • proxy/connection_resume: Test 22 RTN15g/g2 -> RTN14h; the post-TTL reconnect now asserts the resume param is present.
  • completion-status: matrix updated for RTN8d/RTN9d, RTN14h, RTN16g3, RTL15b2.

@SimonWoolf
SimonWoolf requested a review from ttypic July 23, 2026 18:07

@ttypic ttypic left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Spec PR #488 ("Move resumability decisions from the client to the
server", specification version 6.1.0) updated features.md and
api-docstrings.md but did not update the UTS test-spec sources or address
createRecoveryKey's behaviour in SUSPENDED. This brings both in line.

features.md:
- RTN16g2 is replaced by RTN16g3: createRecoveryKey() no longer returns
  Null in SUSPENDED. Since the client now retains its connectionKey and
  always attempts to resume (RTN14h), the connection remains recoverable
  while suspended. (RTN16g2 as written still listed SUSPENDED, which
  contradicts RTN8d/RTN9d retaining the key.)

UTS sources:
- connection_id_key: RTN8c/RTN9c "id/key null in SUSPENDED" -> RTN8d/RTN9d
  "id/key retained in SUSPENDED" (connect first, then suspend).
- connection_failures: RTN15g "no resume after connectionStateTtl"
  -> RTN14h "still attempts resume after the TTL", asserting every
  post-suspension reconnect carries resume=<connectionKey>.
- connection_recovery: RTN16g2 -> RTN16g3; the SUSPENDED case now expects
  a non-null recovery key.
- channel_properties: RTL15b1 "channelSerial cleared on suspended"
  -> RTL15b2 "retained in suspended"; detach/failed cases relabelled.
- channel_attach: RTL4j "ATTACH_RESUME set on reattach" -> "not set".
- proxy/connection_resume: Test 22 RTN15g/g2 -> RTN14h; the post-TTL
  reconnect now asserts the resume param is present.
- completion-status: matrix updated for RTN8d/RTN9d, RTN14h, RTN16g3,
  RTL15b2.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants