Skip to content

Conversation

@benjirewis
Copy link
Member

RSDK-12896

Prunes entries from rc.requestsPerPC and rc.pcToClientMetadata maps when a request limit exceeded log is generated and a PC has actually been closed (used to be when 5s had passed according to connection time, which was always "" for a closed connection). Adds a test that this pruning works.

@benjirewis benjirewis requested review from cheukt and jmatth December 9, 2025 18:55
@viambot viambot added the safe to test This pull request is marked safe to test from a trusted zone label Dec 9, 2025
// It will take ~1s for pion to register the connection as closed on the server. We
// can't _only_ assert on conn.PeerConn().ConnectionState() here because that's the
// client-side.
time.Sleep(3 * time.Second)
Copy link
Member Author

Choose a reason for hiding this comment

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

🤮 lmk if you have better ideas.

Copy link
Member

Choose a reason for hiding this comment

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

can you check the peer conn on the web server directly? Like if you passed the id of the peer conn into some kind of webSvc.PCIsClosed function, and have the request counter on the web service check that pc maybe? or a separate function for testing that returns all pcs currently tracked on the request counter?

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks for ideas! I think they could work, but I opted for something a bit more hacky.

can you check the peer conn on the web server directly? Like if you passed the id of the peer conn into some kind of webSvc.PCIsClosed function, and have the request counter on the web service check that pc maybe?

Unfortunately the peer connection ID is different on the client and server-side, so conn.PeerConn() from the client-side doesn't give us much information on what the corresponding connection on the server-side will look like.

or a separate function for testing that returns all pcs currently tracked on the request counter?

That's certainly doable, but the pruning of the inactive connection will only actually happen on the next emission of Request limit exceeded, so I can't wait for the number of currently-tracked PCs to drop to 0 at the point where I currently have testutils.WaitForAssertion.

I opted for a third solution which was to wait for the two "connection closed" logs to be emitted: one from the client-side and one from the server-side. This solution does rely on the messaging and fields remaining consistent for those logs, but at least there's no time.Sleep(3 * time.Second) that's bound to flake at some point.

@benjirewis benjirewis marked this pull request as ready for review December 9, 2025 18:56
Copy link
Member

@cheukt cheukt left a comment

Choose a reason for hiding this comment

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

looks fine to me, but an idea for the test

// It will take ~1s for pion to register the connection as closed on the server. We
// can't _only_ assert on conn.PeerConn().ConnectionState() here because that's the
// client-side.
time.Sleep(3 * time.Second)
Copy link
Member

Choose a reason for hiding this comment

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

can you check the peer conn on the web server directly? Like if you passed the id of the peer conn into some kind of webSvc.PCIsClosed function, and have the request counter on the web service check that pc maybe? or a separate function for testing that returns all pcs currently tracked on the request counter?

@viambot viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Dec 10, 2025
@benjirewis benjirewis merged commit 9340848 into viamrobotics:main Dec 11, 2025
34 of 36 checks passed
@benjirewis benjirewis deleted the fix-request-limit-exceeded branch December 11, 2025 15:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

safe to test This pull request is marked safe to test from a trusted zone

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants