Skip to content

Conversation

esabol
Copy link

@esabol esabol commented Sep 15, 2025

This PR partially addresses issue #123 by changing the configured value of the server timeout for the docker-events backend from 0 to 30s. It silences the following warning message:

[WARNING] While not properly invalid, you will certainly encounter various problems with such a configuration. To fix this, please ensure that all following timeouts are set to a non-zero value: 'client', 'connect', 'server'.

This partially addresses issue Tecnativa#123 by changing the configured value of the server timeout for the docker-events backend from 0 to 30s. It silences the following warning message:

[WARNING] While not properly invalid, you will certainly encounter various problems with such a configuration. To fix this, please ensure that all following timeouts are set to a non-zero value: 'client', 'connect', 'server'.
Copy link
Member

@pedrobaeza pedrobaeza left a comment

Choose a reason for hiding this comment

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

Isn't the amount very high?

@josep-tecnativa
Copy link
Contributor

Maybe a better timeout would be something like 5 or 10 seconds

@esabol
Copy link
Author

esabol commented Sep 26, 2025

@pedrobaeza @josep-tecnativa : I'm happy to use whichever number you prefer. 30 is just what was suggested in issue #123.

@esabol
Copy link
Author

esabol commented Sep 26, 2025

It's been pointed out that the 0 value comes from PR #98. Maybe this shouldn't be changed?

@josep-tecnativa
Copy link
Contributor

Thanks for sharing this PR. I’ve been investigating a bit, and the /events endpoint is a long-lived streaming connection. Docker keeps sending data as long as the client is listening, so the connection doesn’t really hang. That’s why a timeout is not needed here — setting one would only risk breaking valid event streams. I see that the 0 value comes from PR #98
, so maybe it was intentional for this reason. In any case, the warning fix doesn’t really seem to come from changing the timeout — or at least it’s not a valid solution for us, since it could cause issues.

I'm closing this PR. Thank you anyway.

@esabol
Copy link
Author

esabol commented Sep 26, 2025

In any case, the warning fix doesn’t really seem to come from changing the timeout

Changing the timeout definitely does eliminate the warning message. I tested that. That said, I agree that it shouldn't be changed just to eliminate the warning message for the reason given in PR #98.

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.

3 participants