Skip to content
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

Provide invocation arguments for RepositoryMethodInvocation #2677

Open
roookeee opened this issue Aug 18, 2022 · 2 comments
Open

Provide invocation arguments for RepositoryMethodInvocation #2677

roookeee opened this issue Aug 18, 2022 · 2 comments
Assignees
Labels
status: ideal-for-contribution An issue that a contributor can help us with type: enhancement A general enhancement

Comments

@roookeee
Copy link

roookeee commented Aug 18, 2022

RepositoryTagsProvider of spring-boot-actuator is based on RepositoryMethodInvocation which is defined here.
We would like to tag our repository metrics based on the passed arguments to provide more granular metrics. For example: We have a query that takes a List<String> and we want to track metrics for each size of the given parameter, as the query has / may have difference performance characteristics when being passed 1 vs. 100 ids. This would skew the gathered metrics and overall make the metrics unusable as they can't be interpreted correctly (1 size calls skews min, 100 skews max, average is a hot mess).

From reading the code RepositoryMethodInvocation could be passed the arguments of the actual invocation which would then be available to the RepositoryTagsProvider. Is there any downside to this? Are the arguments only the repository method call arguments or are there some framework related arguments present?

Thank you for your time. I would be willing to do a PR for this if you agree that this should be done.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Aug 18, 2022
@mp911de
Copy link
Member

mp911de commented Aug 18, 2022

Generally speaking, providing arguments would be possible but any argument-post-processing (unwrapping Optional, Future) would be up to your code. Also, any reactive arguments (Mono<Person>) would be passed on as-is and you are not able to consume those parameters in an non-blocking way.

Feel free to submit a pull request.

@mp911de mp911de added status: ideal-for-contribution An issue that a contributor can help us with type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged labels Aug 18, 2022
@roookeee
Copy link
Author

I created a PR for this issue here. Let me know if you want any adjustments via comments in there

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: ideal-for-contribution An issue that a contributor can help us with type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

3 participants