-
Notifications
You must be signed in to change notification settings - Fork 293
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
Fixes #37871 - Granular capsule update content counts #11176
Conversation
482690b
to
9c31757
Compare
During writing test automation an issue was discovered. I tried to workaround it but it persists even for the scenario when we filter out some content from a CV and publish/promote/sync it to the Capsule while automatic content counts update is disabled. So we end up with a new CV version present on the capsule (which is displayed correctly) but no counts calculated for it. UI wrongly says it's empty and hammer fails. |
9c31757
to
37037cb
Compare
37037cb
to
2427743
Compare
e26f844
to
7ff5621
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is working well in my testing so far! I want to do a little more testing with more repositories, but all of the functionality works fine with one smart proxy, 2 LCEs, and one content view.
7ff5621
to
4e6c89b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Working well for me! Tested with varying numbers of content views. I even tested with 2000, but it wasn't super helpful because it totally bogged down the puma workers. That's a pretty ridiculous amount of CVs, fortunately.
What are the changes introduced in this pull request?
The PR introduces parameters to control granularity of the smart proxy content counting method.
Considerations taken when implementing this change?
I had to acquire a lock on the proxy record because parallel sync tasks run for individual environments when a CV version is promoted to them. And each individual sync task triggers it's own content counting leading to a race condition where the last task that saves content_counts overwrites changes by other tasks.
What are the testing steps for this pull request?
To test: