-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
State cache validity check is flaky #431
Comments
Hello, thank you very much for reporting this! 👍 Agree that the current implementation is naïve, just please refer to getStateforCache method - this is where the state is computed, and there is already some kind of normalization. So feel free to prepare a PR that would improve this behavior 🙏 Also, please note that there is already removal of the |
The problem still exists in version 0.17.12 and affects published ports. Each time the An example of the difference in my case:
versus
As you can see, in the first case IPv6 appeared first, and in the second case it is IPv4. |
My implementation for solving this problem in PR #470. |
I noticed, that composeUp sometimes takes 4-5 seconds, even when the containers are running from previous execution.
At other times, it is very fast, less than half a second.
On slow runs, the following is logged: "Current and cached states are different, cannot use the cached service infos.", after which some slow steps, including slow tcp checks, are done.
I realised, that the check here is a bit naive, not considering, that the arrays can have a different order.
For example, first cache state:
and second cache state:
are semantically the same, however have a order difference of "Mounts:ac8a97f7ce79f3…,7111d5ab0ca1f2…,1fd0fecccf9c54…" vs "Mounts:1fd0fecccf9c54…,ac8a97f7ce79f3…,7111d5ab0ca1f2...".
Expected behaviours:
In any case, this is a minor thing. Thanks for the great library.
Appendix #1: fast run logs:
Appendix #2: slow run logs:
The text was updated successfully, but these errors were encountered: