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.
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
ref(generic-metrics): Migrate UseCaseKey to UseCaseID for organization metrics #51776
ref(generic-metrics): Migrate UseCaseKey to UseCaseID for organization metrics #51776
Changes from 11 commits
38da146
3e2179c
1c40763
74cb79e
37aaa27
2616cca
caae53f
86157c7
22a5f24
fbc7642
2a4e56d
d723e53
62941ea
7a8b3b6
fe2ddef
fce1bf1
bf993a1
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
I don't think we want to do this in one shot (i.e. the UI will still use the strings "performance" and "release-health"
at least in the beginning).
We should convert the query params here from UseCaseKey to UseCaseID in here,
something like:
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.
Do you mean our API should accept the following for now
"performance"
UseCaseID.TRANSACTIONS
"transactions"
UseCaseID.TRANSACTIONS
"sessions"
UseCaseID.SESSIONS
"release-health"
UseCaseID.SESSIONS
Once this pr is deployed, and the front end changes made, we will change the API again so that it will accept:
"transactions"
UseCaseID.TRANSACTIONS
"sessions"
UseCaseID.SESSIONS
How does that sound?
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.
Hey John,
If it was up to me I would just keep the external interface fixed ( i.e. emit and accept the strings "performance" and "release-health" .
What you propose is much cleaner, and also harder.
If we change our endpoint to also accept "transactions" and "sessions" there is no harm done, we are still backward compatible.
At that point in time we can also change the UI to both accept and send "transactions" and "sessions".
Changing the backend to emit (in the response) "transactions" and "sessions" or stop accepting "release-health" and "performance" in its parameters breaks backward compatibility and I'm not quite sure what is our policy on that.
We need to take in account that we potentially have external users that are using the API (all our endpoints are considered public API) and if we do that we'll break them ( for no good reason IMO).
Before breaking compatibility we should check if that's acceptable (not sure who we should ask).
As a compromise we could make the Backend accept "transactions" and "sessions" ( in addition to "release-health" and "performance" ) and maybe make the UI send "transactions" and "sessions" and also accept "transactions" and "sessions" in addition to "release-health" and "performance".
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.
I see, thanks!
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.
I would not do it here ( but at the call site... as high as possible).
I would leave
reverse_resolve_tag_value
,reverse_resolve
,reverse_resolve_weak
,resolve
... to take onlyUseCaseID
.If we allow them to take either UseCaseKey or UseCaseID we just moved the problem from the indexer here ( an improvment but not by much).
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.
I agree with @RaduW on this. I would prefer to have all the downstream methods accept
UseCaseId
and perform coercions at top level if we don't want to also refactor there.