rgw: handle EINVAL translation in forward_request#60899
Conversation
src/rgw/rgw_rest_client.cc
Outdated
| int r = process(dpp, y); | ||
| if (r < 0){ | ||
| if (r == -EINVAL){ | ||
| if (r == -EINVAL && http_status == 0) { // make sure no header were received |
There was a problem hiding this comment.
I wonder if we can just leave http_status in the if clause so we return 503 on all internal curl errors no matter what the return code is.
There was a problem hiding this comment.
hard to know what issues this could cause. let's see what multisite tests do with just if (http_status == 0)?
There was a problem hiding this comment.
Updated with only the http_status case.
RGWRESTSimpleRequest::forward_request() translates EINVAL to a 503 status code to reflect connection errors as internal errors rather than client errors. However, if the master is explicitly returning EINVAL (which corresponds to an HTTP 400 status code), this translation incorrectly converts it to 503, hiding the true client error. To address this, we now check the HTTP status code to ensure the error originates from easy_curl and not from a valid HTTP response, preserving the intended 400 status when appropriate. Fixes: https://tracker.ceph.com/issues/69084 Signed-off-by: Seena Fallah <[email protected]>
|
jenkins test api |
|
jenkins test api |
|
This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days. |
oh hell. apparently the only workaround is to close/reopen the pr and pass all the checks again 😿 |
cbodley
left a comment
cbodley
left a comment
There was a problem hiding this comment.
seems to work in testing. yolo?
cbodley
added
TESTED
ready-to-merge
and removed
needs-qa
needs-review
wip-cbodley-testing
labels
i guess in |
|
jenkins test make check arm64 |
4 participants
RGWRESTSimpleRequest::forward_request() translates EINVAL to a 503 status code to reflect connection errors as internal errors rather than client errors. However, if the master is explicitly returning EINVAL (which corresponds to an HTTP 400 status code), this translation incorrectly converts it to 503, hiding the true client error.
To address this, we now check the HTTP status code to ensure the error originates from easy_curl and not from a valid HTTP response, preserving the intended 400 status when appropriate.
Fixes: https://tracker.ceph.com/issues/69084