-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in 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: