Skip to content

Conversation

@afrind
Copy link
Collaborator

@afrind afrind commented Oct 23, 2025

This also restricts joining fetch to subscriptions in Forward State=1, since joining a subscription in Forward State 0 does not have the intended "no gaps" effect.

This means that subscriptions initiated in Forward=0 need to update the join point when Forward transitions to 1. Possible flow:

P->S: PUBLISH, Forward=0, Largest Object={10, 5}
P: Object 11,0
S->P: PUBLISH_OK, Forward=1
S->P: Joining FETCH
P->S: FETCH_OK, End=11,0 (inclusive)
P->S (fetch stream): 11,0
P->S (subscribe stream): Object 11,1

Note in the above flow, a standalone FETCH to Largest Object would miss 11,0.

This PR also allows re-joining a track that was temporarily in Forward=0:

S->P: SUBSCRIBE, Forward=1
S->P: Joining FETCH
...
S->P: SUBSCRIBE_UDPATE, Forward=0
...
S->P: SUBSCRIBE_UDPATE, Forward=1
S->P: Joining FETCH
P->S: REQUEST_OK, Largest={21,0}
P->S (fetch stream): Object 21,0

Addresses an issue raised in #1313

This also restricts joining fetch to subscriptions in Forward State=1, since joining a subscription in Forward State 0 does not have the intended "no gaps" effect.

This means that subscriptions initiated in Forward=0 need to update the join point when Forward transitions to 1.  Possible flow:

```
P->S: PUBLISH, Forward=0, Largest Object={10, 5}
P: Object 11,0
S->P: PUBLISH_OK, Forward=1
S->P: Joining FETCH
P->S: FETCH_OK, End=11,0 (inclusive)
P->S (fetch stream): 11,0
P->S (subscribe stream): Object 11,1
```

Note in the above flow, a standalone FETCH to Largest Object would miss 11,0.

This PR also allows re-joining a track that was temporarily in Forward=0:

```
S->P: SUBSCRIBE, Forward=1
S->P: Joining FETCH
...
S->P: SUBSCRIBE_UDPATE, Forward=0
...
S->P: SUBSCRIBE_UDPATE, Forward=1
S->P: Joining FETCH
P->S: REQUEST_OK, Largest={21,0}
P->S (fetch stream): Object 21,0
```
@afrind afrind added Design Issues or PRs that change how MoQ works including the wire format. Fetch Issues related to Fetch. labels Oct 23, 2025
Co-authored-by: Suhas Nandakumar <[email protected]>
Co-authored-by: Ye-Kui Wang <[email protected]>
@ianswett
Copy link
Collaborator

ianswett commented Nov 4, 2025

Based on my initial review, I think this PR looks sensible and it's definitely a use case worth solving, but this feels bad.

* Joining Request ID: The Request ID of the `Established` subscription to be
joined. If a publisher receives a Joining Fetch with a Request ID that does
not correspond to an existing Subscribe in the same session, it MUST return
not correspond to an `Established` subscription in the same session, it MUST return
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Some other states are valid. Pending (subscriber)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Fixed in #1363

@ianswett ianswett added the Parked Issue we may discuss later or close as OBE label Nov 8, 2025
@afrind afrind changed the title Allow joining FETCH for PUBLISH Allow joining FETCH for PUBLISH and SUBSCRIBE_UPDATE forward=1 Nov 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Design Issues or PRs that change how MoQ works including the wire format. Fetch Issues related to Fetch. Parked Issue we may discuss later or close as OBE

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants