Skip to content

fix(connlib): clear join requests on reconnect - #9985

Merged
thomaseizinger merged 3 commits into
mainfrom
chore/clear-pending-join-requests
Jul 24, 2025
Merged

fix(connlib): clear join requests on reconnect#9985
thomaseizinger merged 3 commits into
mainfrom
chore/clear-pending-join-requests

Conversation

@thomaseizinger

Copy link
Copy Markdown
Member

Room join requests on the portal are only valid whilst we have a WebSocket connection. To make sure the portal processes all our requests correctly, we need to hold all other messages back while we are waiting to join the room.

If the connection flaps while we are waiting to join a room, we may have a lingering join request that never gets fulfilled and thus blocks the sending of messages forever.

@thomaseizinger
thomaseizinger requested a review from jamilbk July 24, 2025 04:55
@vercel

vercel Bot commented Jul 24, 2025

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
firezone ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jul 24, 2025 0:30am

@thomaseizinger
thomaseizinger enabled auto-merge July 24, 2025 04:55

@jamilbk jamilbk left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Good catch. I think I've hit this one too but hard to reproduce. I added changelogs.

@jamilbk jamilbk left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I believed I just managed to reproduce this locally.

firezone_tunnel::unique_packet_buffer: Buffering packet tag=pending-flow-resources is_full=false packet=Packet { src: 100.82.80.16, dst: 1.1.1.1, protocol: "ICMP", icmp_type: EchoRequest(IcmpEchoHeader { id: 35907, seq: 157 }) } resource=...
firezone_tunnel::unique_packet_buffer: Buffering packet tag=pending-flow-resources is_full=false packet=Packet { src: 100.82.80.16, dst: 1.1.1.1, protocol: "ICMP", icmp_type: EchoRequest(IcmpEchoHeader { id: 35907, seq: 158 }) } resource=...
firezone_tunnel::client: Sending connection intent resource=...

Stuck forever in this loop.

@jamilbk

jamilbk commented Jul 24, 2025

Copy link
Copy Markdown
Member

Seems that there's a flaky test - https://github.com/firezone/firezone/actions/runs/16496872800/job/46644656743?pr=9985

I'm actually able to hit this quite reliably with the following test plan:

  1. Force relayed connection
  2. Enable internet resource
  3. Roam between interfaces

All packets essentially get buffered and my internet "goes down". Happy to paste a log if you want to validate this PR will fix the issue.

@thomaseizinger

Copy link
Copy Markdown
Member Author

I'm actually able to hit this quite reliably with the following test plan:

1. Force relayed connection

2. Enable internet resource

3. Roam between interfaces

All packets essentially get buffered and my internet "goes down". Happy to paste a log if you want to validate this PR will fix the issue.

Yeah I think successive resets will trigger this easily. Just needs a reset at the right time, i.e. when we have already sent the join request but not received the reply yet.

@thomaseizinger
thomaseizinger added this pull request to the merge queue Jul 24, 2025
Merged via the queue into main with commit cbe114b Jul 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants