-
Notifications
You must be signed in to change notification settings - Fork 29
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
HTTPError 406 CustomNotAcceptable encountered intermittently #58
Comments
This seems may possibly be related to the following known issue |
edgarrmondragon
pushed a commit
that referenced
this issue
Mar 27, 2024
We have been noticing 406 errors when running discovery, specifically on the `.../describe` endpoint. ``` requests.exceptions.HTTPError: 406 Client Error: CustomNotAcceptable for url: https://XXX.salesforce.com/services/data/v53.0/sobjects/XXX/describe ``` This MR adds error handling for this. The error code 406 is new to me, so I wanted to look up what that meant. Salesforce's error codes page does not even document it. https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/errorcodes.htm From the various pieces of literature I've read, it seems that the way to correct this issue is to set one of the accept, accept-encoding & accept-language appropriately, however we have not been providing alternate values for these headers and the error is encountered intermittently. My best guess is that a separate issue occurs, but salesforce does not report the actual error, and instead we are returned a 406, which is not very meaningful. To recover from these failures, we simply rerun the taps. However, adding a retry specific to this error code seems like a better approach and it will benefit the wider meltano / singer community. MDN defines 406 as >The HyperText Transfer Protocol (HTTP) 406 Not Acceptable client error response code indicates that the server cannot produce a response matching the list of acceptable values defined in the request's proactive content negotiation headers, and that the server is unwilling to supply a default representation. > >In practice, this error is very rarely used. Instead of responding using this error code, which would be cryptic for the end user and difficult to fix, servers ignore the relevant header and serve an actual page to the user. It is assumed that even if the user won't be completely happy, they will prefer this to an error code. > >If a server returns such an error status, the body of the message should contain the list of the available representations of the resources, allowing the user to choose among them. source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/406 Found the following through more google searches: https://zendenwebdesign.com/causes-and-fixes-for-406-error-not-acceptable/ and also, in the salesforce community forums, users reported seeing this type of error: https://trailhead.salesforce.com/trailblazer-community/feed/0D54S00000A93GsSAJ # Related Issues - closes: #58
We're hitting this as well with the Salesforce API and we don't use tap-salesforce (we make direct requests). It started about 3 days ago. Very intermittent, even with identical requests. |
nezd
pushed a commit
to dext/tap-salesforce
that referenced
this issue
Sep 26, 2024
We have been noticing 406 errors when running discovery, specifically on the `.../describe` endpoint. ``` requests.exceptions.HTTPError: 406 Client Error: CustomNotAcceptable for url: https://XXX.salesforce.com/services/data/v53.0/sobjects/XXX/describe ``` This MR adds error handling for this. The error code 406 is new to me, so I wanted to look up what that meant. Salesforce's error codes page does not even document it. https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/errorcodes.htm From the various pieces of literature I've read, it seems that the way to correct this issue is to set one of the accept, accept-encoding & accept-language appropriately, however we have not been providing alternate values for these headers and the error is encountered intermittently. My best guess is that a separate issue occurs, but salesforce does not report the actual error, and instead we are returned a 406, which is not very meaningful. To recover from these failures, we simply rerun the taps. However, adding a retry specific to this error code seems like a better approach and it will benefit the wider meltano / singer community. MDN defines 406 as >The HyperText Transfer Protocol (HTTP) 406 Not Acceptable client error response code indicates that the server cannot produce a response matching the list of acceptable values defined in the request's proactive content negotiation headers, and that the server is unwilling to supply a default representation. > >In practice, this error is very rarely used. Instead of responding using this error code, which would be cryptic for the end user and difficult to fix, servers ignore the relevant header and serve an actual page to the user. It is assumed that even if the user won't be completely happy, they will prefer this to an error code. > >If a server returns such an error status, the body of the message should contain the list of the available representations of the resources, allowing the user to choose among them. source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/406 Found the following through more google searches: https://zendenwebdesign.com/causes-and-fixes-for-406-error-not-acceptable/ and also, in the salesforce community forums, users reported seeing this type of error: https://trailhead.salesforce.com/trailblazer-community/feed/0D54S00000A93GsSAJ # Related Issues - closes: MeltanoLabs#58
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
We sometimes encounter the following error during discovery.
However, on retrying manually, the taps runs fine. We believe this is an intermittent failure & perhaps salesforce is reporting an incorrect error, thereby masking the true cause of failure.
Since the error is recovered through retries, I feel that its probably good to add this error to backoff's list of exceptions to retry on.
The text was updated successfully, but these errors were encountered: