WPCOM memberships endpoint returns incorrect 500 status code

Open sathyapulse opened this issue 1 year ago • 1 comments

Impacted plugin

Jetpack

Quick summary

One of our customers was concerned about the 500 errors in the application. After further investigation, we found that the membership status endpoint returns a 500 status code when the user account is not connected to WordPress.com. It looks like the intended status code is 404, but the API returns a 500 status code due to incorrect usage of status code in the third parameter.

In the same method, the third parameter is used correctly to return the intended 404 status code. Can we please audit the status codes in the file and fix the status codes?

Steps to reproduce

The requests to the endpoint are triggered from the Block Editor.

https://example.com/wp-json/wpcom/v2/memberships/status?source=gutenberg&type=all&is_editable=true&_locale=user

A clear and concise description of what you expected to happen.

The expected 404 status code should be returned from the API.

What actually happened

No response

Impact

All

Available workarounds?

There is no user impact

If the above answer is "Yes...", outline the workaround.

No response

Platform (Simple and/or Atomic)

No response

Logs or notes

No response

Aug 30 '24 06:08 sathyapulse

Since it seemed likely we have more instances of this than just the one file, I used Phan to scan the entire monorepo.

It turned up 456 places where we pass an int to `WP_Error`'s data parameter, all of which look likely to be intended as an HTTP status code.

But on further review, I don't think all of these would be correctly changed to array( 'status' => X ). The ones in projects/plugins/jetpack/_inc/lib/core-api/ are probably going through Core's API and so are good to change, but on the other hand the ones in projects/plugins/jetpack/json-endpoints/ seem more likely to be going through this bit of code that wants either the bare int or array( 'status_code' => X ) https://github.com/Automattic/jetpack/blob/cd0ac7a8754487a5cbccb4e39b4a7f6aa0ada4bb/projects/plugins/jetpack/class.json-api.php#L754-L762 We may need to check that neither of the APIs are using the other's classes as a backend. And we may need to check what code on wpcom Simple does with any of this too.

As for everything else, does it go through one of those APIs, or both, or neither?

That's as far as I have time to take this right now. Anyone else is free to pick it up.

Aug 30 '24 14:08 anomiex

This seems to now be impacting multiple customers of WP VIP. It may be a change in the most recent update of Jetpack, or at least within the last few versions. Our latest customer report was after a Jetpack automatic upgrade to version 13.9.

Oct 28 '24 15:10 ThirdEyeRose

@ThirdEyeRose @anomiex This is now fixed (at least for the Memberships status).

It turned up 456 places where we pass an int to WP_Error's data parameter, all of which look likely to be intended as an HTTP status code.

Maybe you should open a new issue regarding this.

CC @jeherve

Nov 07 '24 09:11 millerf

Hi @millerf - we have another customer seemingly observing the same issue in 197974-z - they're seeing 500 responses being returned for this endpoint:

/wp-json/wpcom/v2/memberships/status?source=gutenberg&type=all&is_editable=true&_locale=user

Is there a specific version of Jetpack that has the fix in place? Based on the PR, I think it should be fixed in 13.9.1? Fwiw, their WP version is currently 6.6, and Jetpack version is 14.0. Please also let me know if you need any further details here!

Dec 09 '24 08:12 suyogyashukla

Hi @millerf - we have another customer seemingly observing the same issue in 197974-z - they're seeing 500 responses being returned for this endpoint:

@suyogyashukla

Can you please tell me their blog ID or URL? I don't have access to the ticket... It would also help making sure their jetpack connection works fine with Pc9OEs-v-p2

Dec 09 '24 13:12 millerf