Skip to content

Conversation

@jsternberg
Copy link
Collaborator

The unit test can potentially deadlock in some way that the go runtime
doesn't detect it and it runs for 30 minutes. Skipping the test until we
either fix it or replace it with an equivalent integration test.

The unit test can potentially deadlock in some way that the go runtime
doesn't detect it and it runs for 30 minutes. Skipping the test until we
either fix it or replace it with an equivalent integration test.

Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Copy link
Contributor

@rcjsuen rcjsuen left a comment

Choose a reason for hiding this comment

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

Sorry about this, folks. :(

@rcjsuen
Copy link
Contributor

rcjsuen commented Dec 12, 2025

Do we have an issue created to remind ourselves to review this?

@jsternberg
Copy link
Collaborator Author

Not at the moment but I'll probably end up covering it in the integration tests.

@jsternberg
Copy link
Collaborator Author

I found the potential race issue while working on the integration tests which is fixed in this PR: #3566

When the test client makes a request, it registers the request sequence id with a map on the client so it can associate the response to the correct channel. It was adding this sequence id to the map after it sent the message rather than before so receiving the message very quickly could cause the response to be dropped and then code that was polling for the response would hang even though the response had been received.

@tonistiigi tonistiigi closed this Dec 17, 2025
@jsternberg jsternberg deleted the set-breakpoints-skip-test branch December 17, 2025 21:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants