Closed jorgemd24 closed 1 month ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 64.7%. Comparing base (
76d15ab
) to head (007190f
). Report is 27 commits behind head on develop.
I’m wondering if we should adjust this behavior in WPCOM so that if there’s no token to revoke, it simply returns without throwing an error. I’d be happy to hear thoughts on this.
I can't find any documentation about revoking a token, but based on the documentation about validating a token it seems it's common to return an error when the token is not valid (or possibly doesn't exist).
So I'd suggest to keep expecting an error, and just handle it accordingly in the client so they can still proceed.
I can't find any documentation about revoking a token, but based on the documentation about validating a token it seems it's common to return an error when the token is not valid (or possibly doesn't exist).
Thanks for your input! We implemented the endpoint in WPCOM for revoking the GFW token, so it’s great to know we're aligned with the other responses in WPCOM.
Hi @puntope, thanks for the suggestion! I’ve updated the PR to handle the error on the client side instead of the server. I believe it’s better to attempt revoking the token regardless of the WPCOM Auth status in the DB (just to be safe), and as @mikkamp mentioned, this keeps us aligned with the other endpoints. Could you take another look? Thanks!
Changes proposed in this Pull Request:
Closes # .
This PR addresses an issue when attempting to disconnect all accounts on the settings page. The problem occurs when the user hasn't granted access to the new Pull mechanism, but we still try to revoke the wpcom token. Since there’s no token to revoke, WPCOM responds with an error.
I’m wondering if we should adjust this behavior in WPCOM so that if there’s no token to revoke, it simply returns without throwing an error. I’d be happy to hear thoughts on this.
Screenshots:
Detailed test instructions:
Additional details:
Changelog entry