Store: *breaking ⚠️* set debug.advertise-compatibility-label t… #8509
+2
−1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Xaelias
force-pushed
the
fix_-_adhoc_-_2025-10-02_-_Set_debug.advertise-compatibility-label_to_false_by_default
branch
2 times, most recently
from
1ea9df6 to
7417cf8
Compare
… by default (thanos-io#8509) In a previous change back in v0.37.0[^1], we stopped explicitely checking for the compatibility label advertised by the store gateway introduced to ensure compatibility with querier <v0.8.0. However, what didn't happen in that PR is that the thanos will still try to add this label by default[^2]. This change modifies the command line argument to default to NOT adding this compatibility label by default anymore, since this is now the assumption made in code. The reason behind this change is that while upgrading from v0.36.x, we quickly realised that querries were fanning out to all our endpoint-groups, and not abiding by our external labels anymore. [^1]: [pull/7645](https://github.com/thanos-io/thanos/pull/7645/files#diff-fb8e209f24ab370a81b6909a08fd58b18b6dd4a7816597879c08cf5590542b60R800) [^2]: [debug.advertise-compatibility-label](https://github.com/thanos-io/thanos/blob/d997eed1749e4d91243efc0137f6a20cb659841b/cmd/thanos/store.go#L182-L183) Signed-off-by: Alexis Lesieur <[email protected]>
Xaelias
force-pushed
the
fix_-_adhoc_-_2025-10-02_-_Set_debug.advertise-compatibility-label_to_false_by_default
branch
from
7417cf8 to
4cbca31
Compare
|
Just out of curiosity - how was the fan-out pruning affected by this? I don't yet fully understand. |
MichaHoffmann
approved these changes
Oct 3, 2025
I'm not gonna lie I'm not the one who found the issue (just the one that was doing the upgrade). But my understanding is that since we went from: (which would effectively "ignore" the compatibility label in this loop) to now we have the problem of |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes
In a previous change back in v0.37.01, we stopped explicitely checking for the compatibility label advertised by the store gateway introduced to ensure compatibility with querier <v0.8.0.
However, what didn't happen in that PR is that the thanos will still try to add this label by default2.
This change modifies the command line argument to default to NOT adding this compatibility label by default anymore, since this is now the assumption made in code.
The reason behind this change is that while upgrading from v0.36.x, we quickly realised that querries were fanning out to all our endpoint-groups, and not abiding by our external labels anymore.
Verification
We've been running with
--no-debug.advertise-compatibility-labelin prod and confirmed the behavior is fixed.PS: Hi 👋 first PR on this project. Apologies if anything doesn't look right, let me know if I need to change aything!
Footnotes
pull/7645 ↩
debug.advertise-compatibility-label ↩