Screenshare not always published

[otakueadwine]

Describe the bug

When I select a screen to share, then share it, I expect the participants in my room to see it.
When I share it fast enough after the room is created (but after the participants have joined), the track is not shared to the other participants.

Reproduction

In my project a user can trigger a screen share action to a specific user. When this action is triggered the following things happen:

• The initiator / sender creates a livekit room, joins it and triggers the setScreenShareEnabled so they can select a screen.
• The receiver will auto-open a new page that will automatically open the specific room and join the user.

If the initiator quickly chooses a screen to share and then shares it, the track does not get communicated to the receiver. When looking at the logs, I do get a "publishing track" log, but the videoTrackPublications of the sender participant remain empty. I also have a log on RoomEvent.TrackSubscribed, but this event does not get triggered.
In below screenshot, on the left side you see a log from the receiver side, showing the RemoteParticipant (aka the sender). The right side shows the sender side.

If I wait a few seconds before selecting a screen, I get the "waiting for pending publication promise timed out" log. If I then select the screen, the video track correctly gets published to the receiver.
On the left it's the receiver and on the right the sender.

I've added files with log level 'debug' in the additional info section (without my custom logs that I showed above)

Upon further inspection I also noticed that the LocalTrackPublication that I receive from setScreenShareEnabled has no actual track. That value remains undefined.

Logs

System Info

This is my setup, but our customers use all kinds of devices and browser versions, including chromebooks.

System:
    OS: macOS 26.0.1
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
    Memory: 103.82 MB / 16.00 GB
    Shell: 5.9
  Binaries:
    Node: 22.20.0
    Yarn: 1.22.18
    npm: 10.9.3
  Browsers:
    Chrome: 142.0.7444.60
    Chrome Canary: 144.0.7512.1
  npmPackages:
    @livekit/components-react: ^2.9.15 => 2.9.15
    livekit-client: ^2.15.14 => 2.15.14

Severity

serious, but I can work around it

Additional Information

logs-success-receiver.log
logs-success-sender.log
logs-bugged-receiver.log
logs-bugged-sender.log

[lukasIO]

Thanks for the report.

Could you please share a minimal example that reproduces the issue?

[otakueadwine]

@lukasIO
I've spent a bit of time trying to make a POC based off of a LiveKit Cloud server and using a web socket as replacement of our browser plugin (which is responsible for opening the tab on the Receiver).
Tried a few things with timing here and there, but was not able to reproduce the bug :') Guess there are just too many variables with the loading of a tab and then setting up the livekit connection.
In my own project I'm able to reproduce it every time. We will spend some time refactoring the (old) logic that we have in place, perhaps that will fix the issue, but to me it's still vague that in the logs it does seem to be a problem on livekit's side.