One of my customer is getting error code 21005, tough he has a valid subscription..
As per apple docs, it is given "The receipt server is not currently available." for 21005.
Anybody knows what does exactly the error means.
we got them too about 36 hours ago. I think it means what it said, some of the servers had downtime.
Related
I´m trying to deploy a AWS EC2 Mac instance.
During the process of setting the instance up, I get asked to allocate a dedicated host for it.
When I try to do it, I keep getting the following message:
Your request for accessing resources in this region is being validated, and you will not be able to launch additional resources in this region until the validation is complete. We will notify you by email once your request has been validated. While normally resolved within minutes, please allow up to 4 hours for this process to complete. If the issue still persists, please let us know by writing to aws-verification#amazon.com for further assistance.
It´s been more than a day since I started trying, so the problem isn´t the 4 hours mentioned in the message.
Anyone has any ideas how to solve this?
Thank you!
Is the AWS account in which you are trying to provision those resources brand new?
Messages like the one you are seeing are usually seen in case the account in question hasn't been fully activated or lacks billing information.
If my assumption is correct check the root account email inbox for confirmation/verification email requests from AWS. And make sure that your credit card information is up to date.
I'm getting errors when I try to deploy a Google Cloud Function. The process hangs for about 5-10 minutes and then an error appears:
"Deployment failure:
Operation interrupted."
I tried creating a new test function with nothing in it in two different projects of mine, both are timing out with that same error.
Anyone experiencing anything similar?
There was an incident related to Cloud Functions and Cloud Build that began at 2019-09-24 13:00 and ended at 2019-09-24 18:15 (all times are US/Pacific).
It should be all good now. Please try to deploy your function again.
In case it will not work for you. Please update your question to contain more information: minimum reproducible code, dependencies, timestamp.
Yes, having the same issue here. Tried to check status on their dashboard they mark it has ok but it's not.
Error description
Upon calling DialogFlow v2 detectIntent API, we randomly get an internal error with status code 13:
Webhook call failed. Fetch failure with no HTTP status code. Status: State: URL_REJECTED Reason: 67
This error seems to happen randomly. The same request can succeed or fail.
Interesting point, the service has been deteriorating since Friday 23th August 2019, to fail on almost every call today.
Our investigation
We didn't find anything at all about URL_REJECTED with DialogFlow or Google on internet.
But we found the meaning of the status code 13 on this page:
Internal errors. This means that some invariants expected by the underlying system have been broken. This error code is reserved for serious errors.
We also checked that we aren't banning Google IP, our that our load-balancing is not messed up (we thought of that since it would make sense with random fails).
The webhook is up and running, and we can call it ourselves. The problem seems to happen in Google's infra, as the error code 13 seems to show.
(I answer immediatly because we fixed it before posting the question. But I posted nevertheless because it may be useful for others)
The problem was that the webhook was called using http.
Setting https solved the problem.
It seems that Google activated a webhook policy of rejecting unsecure calls in their servers.
It may have been deployed gradually on their cluster, which would explain the gradual degradation.
We know that we should have migrated to https a long time ago, but still we didn't find any mention of the application of this policy on the net.
Thank you for posting this. I came across the same issue. Changed my webhook to HTTPS seems to fix the problem.
3 days ago we received an alert from the facebook developers page inform us that one of our apps had reached 100% of the hourly rate limit. Our application had an error that caused the increase in calls to the APIS that we solved yesterday afternoon. Since that we deployed the fix we see that in API calls graph (graph: "Application Level Rate Limiting") we don't reach the limit but the calls to the facebook APIS still failing. We want to know if there is a period of time to recover access to the APIs after not reaching that limit.
Here you can see a screenshot of the alert:
alert
In the response headers of one of the calls, we receive this error:
Status code: 403
Header name: WWW-Authenticate
Header value: OAuth "Facebook Platform" "invalid_request" "(#4) Application request limit reached
You can see the header here
You are not the only one right now:
https://developers.facebook.com/support/bugs/169774397034403/
But i suppose it should be gone after a day or a few hours, in my experience, sometimes i can make a few calls and then it shuts me off again, while our application is not that api call intensive.
This is the response from Facebook:
Dear all,
We checked with our rate limiting team who confirmed that several
improvements were made to help you troubleshoot rate limit related
error messages. For example, we've fixed an existing graph and added a
new one in the app dashboard to give you more info about the status of
your app.
If you continue to receive error code #4 in your request, we'd
appreciate it if you can create a new bug report because this thread
is getting rather long. We'll be happy to analyze each individual case
for you if you can provide the following info:
your app id the entire error message include the trace id a screenshot
of the graphs on your app dashboard
Thanks for your patience while we looked into this.
Xiao
I'm trying several times to deploy a new version of a service on my app engine flexible instance using the sdk and the command gcloud app deploy, but all i get is this error
"ERROR: (gcloud.app.deploy) Error Response: [4] Timed out waiting for
the app infrastructure to become healthy."
.
I Couldn't found any answer about it on the issue tracker of gcp.
On this question, he got the same problem, but no one could answered it.
Any guidance will be very helpfull.
According to the gcp team, this particular error was caused because we reached the "In-use IP addresses" quota limit.
They also said that are working on improve the error messages.
"The engineering team has just created a fix for better quota error
details. There is no ETA for when the fix will be released, but I
would guess it would be in the next version of gcloud."
Over half a year later after Loneck's answer I've got the same error. I guessed it could be anything. This is why I've choosen to delete the project, create a new one in a new zone and deployed it there. Then it worked for me. It might have been any other limitation in the zone that I've choosen at the beginning.
I ran into this and solved it by retrying the deploy 3 times.