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

Avoid potential NPE in Metrics filter #16628

Merged
merged 1 commit into from
Apr 19, 2021
Merged

Avoid potential NPE in Metrics filter #16628

merged 1 commit into from
Apr 19, 2021

Conversation

geoand
Copy link
Contributor

@geoand geoand commented Apr 19, 2021

The NPE could happen if an exception was thrown
in a ContainerRequestFilter

Fixes: #16620

@quarkus-bot
Copy link

quarkus-bot bot commented Apr 19, 2021

/cc @ebullient, @jmartisk

Copy link
Member

@FroMage FroMage left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit torn about this: it's hard for filter authors to know which (allowed) parameter may be null, and why.

Perhaps it would be better to always have a ResourceInfo even if its methods then throw an exception explaining that there's no resource because we had an exception before we found it.

But this would not make it easier for this particular filter which wants to ignore calls when that happens.

OTOH, is it really normal to invoke response filters when an exception happens that prevents us from finding the target resource?

@FroMage
Copy link
Member

FroMage commented Apr 19, 2021

Well, the spec says "A response mapped from an exception MUST be processed using the filter chain and the interceptor chain (if an entity is present in the mapped response). "

So yeah, we apparently need to invoke them no matter how broken everything else is.

@geoand
Copy link
Contributor Author

geoand commented Apr 19, 2021

So yeah, we apparently need to invoke them no matter how broken everything else is.

Unfortunately yes...

@geoand
Copy link
Contributor Author

geoand commented Apr 19, 2021

Perhaps it would be better to always have a ResourceInfo even if its methods then throw an exception explaining that there's no resource because we had an exception before we found it.

I actually think this would make it even more confusing

@FroMage
Copy link
Member

FroMage commented Apr 19, 2021

OK hold on, the javadoc of ResourceInfo says:

Methods in this class MAY return null if a resource class and method have not been matched, e.g. in a standalone, pre-matching ContainerRequestFilter that was not provided by a post-matching PreMatching.

So that's our answer that is spec-compliant.

Copy link
Member

@FroMage FroMage left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to javadoc, the right thing to do is to have a non-null ResourceInfo and a null return value from its methods. Given that both options are equally confusing IMO, we should implement the one that is documented and has a better interop chance.

@geoand
Copy link
Contributor Author

geoand commented Apr 19, 2021

OK lemme do that

The NPE could happen if an exception was thrown
in a ContainerRequestFilter

Fixes: quarkusio#16620
Copy link
Member

@FroMage FroMage left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, thanks!

@geoand
Copy link
Contributor Author

geoand commented Apr 19, 2021

👍🏼

@geoand geoand added triage/waiting-for-ci Ready to merge when CI successfully finishes and removed area/metrics area/smallrye labels Apr 19, 2021
@geoand geoand merged commit 8d6d08c into quarkusio:main Apr 19, 2021
@quarkus-bot quarkus-bot bot removed the triage/waiting-for-ci Ready to merge when CI successfully finishes label Apr 19, 2021
@quarkus-bot quarkus-bot bot added this to the 2.0 - main milestone Apr 19, 2021
@geoand geoand deleted the #16620 branch April 20, 2021 05:48
@gsmet
Copy link
Member

gsmet commented Apr 26, 2021

@geoand this one conflicts (due to the MP 4 changes). Not sure it's worth rewriting the patch? I'll let you judge of that.

@geoand
Copy link
Contributor Author

geoand commented Apr 26, 2021

I think it's not terribly important, but I'd be up for it if someone complains :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Resteasy Reactive - NPE when a filter throws exceptions
4 participants