profiler/internal/pprofutils: work around breaking pprof change #2515
Conversation
This file contains 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
The Google pprof library introduced a breaking change, adding an extra argument to a function we use. We currently have "smoke tests" which assert that we can unconditionally upgrade every dependency to the latest version and still compile. This commit is meant to satisify that test. We don't actually *need* a newer version of the pprof library. But there is a possibility (however unlikely) that a user wants to handle pprofs separately of our library using that library. Either we upgrade our dependency, breaking them, or they upgrade their dependency, breaking us. To avoid either issue, use an interface assertion to support either version of the API.
BenchmarksBenchmark execution time: 2024-01-18 09:20:16 Comparing candidate commit b9e1da3 in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 39 metrics, 2 unstable metrics. |
darccio
approved these changes
Jan 18, 2024
felixge
approved these changes
Jan 18, 2024
Not right now, since the Go runtime isn't adding this new column record to pprofs yet. But good point, we should keep an eye out for that. |
nsrip-dd
added a commit
that referenced
this pull request
Jan 18, 2024
The Google pprof library introduced a breaking change, adding an extra argument to a function we use. We currently have "smoke tests" which assert that we can unconditionally upgrade every dependency to the latest version and still compile. This commit is meant to satisify that test. We don't actually *need* a newer version of the pprof library. But there is a possibility (however unlikely) that a user wants to handle pprofs separately of our library using that library. Either we upgrade our dependency, breaking them, or they upgrade their dependency, breaking us. To avoid either issue, use an interface assertion to support either version of the API.
katiehockman
pushed a commit
that referenced
this pull request
Jan 18, 2024
The Google pprof library introduced a breaking change, adding an extra argument to a function we use. We currently have "smoke tests" which assert that we can unconditionally upgrade every dependency to the latest version and still compile. This commit is meant to satisify that test. We don't actually *need* a newer version of the pprof library. But there is a possibility (however unlikely) that a user wants to handle pprofs separately of our library using that library. Either we upgrade our dependency, breaking them, or they upgrade their dependency, breaking us. To avoid either issue, use an interface assertion to support either version of the API.
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.
The Google pprof library introduced a breaking change, adding an extra
argument to a function we use. We currently have "smoke tests" which
assert that we can unconditionally upgrade every dependency to the
latest version and still compile.
This PR is meant to satisify that test. We don't actually need a
newer version of the pprof library. But there is a possibility (however
unlikely) that a user wants to handle pprofs separately of our library
using that library. Either we upgrade our dependency, breaking them, or
they upgrade their dependency, breaking us. To avoid either issue, use
an interface assertion to support either version of the API.
Fixes #2519