I am trying to restore a previous backup trough gconsole and json api as well and I am getting the error "The instance or operation is not in an appropriate state to handle the request" what it means? I can't find in the docs, instance is on runnable status
I want to restore a backup because there was some data loss probably due to the fact I am using myisam instead of innodb, not sure if that matters with this issue
any idea?
Thank you
ps:
{
"error": {
"errors": [
{
"domain": "global",
"reason": "invalidState",
"message": "The instance or operation is not in an appropriate state to handle the request."
}
],
"code": 409,
"message": "The instance or operation is not in an appropriate state to handle the request."
}
}
As Juan Enrique pointed out Cloud SQL stores the seven last backups, and it will allow you to restore any of them.
When using the API you may list backups that all the backups, including those older than the seven-last limit, but it won't allow you to restore from any of those.
Related
Hi I am currently working on an app with an in-app-shop. Now I need to implemented Server Side Verification for Google In-app-purchases. We use https://github.com/googleapis/google-api-php-client for the verification. We already got the in app purchases and have tested the in app purchases with the test products (android.test.purchased). Is there a way to test the validation ? In the moment i get the following response when using a "android.test.purchased" for the following call
$googleApiResult = $service->purchases_products->get($_ENV['PACKAGENAME'], $productId, $token);
{
"error": {
"code": 400,
"message": "Invalid Value",
"errors": [
{
"message": "Invalid Value",
"domain": "global",
"reason": "invalid"
}
]
}
}
In the docs it states that you need the productive data. The app has already an Alpha Track. On the alpha track in the Google Store the in app purchases are also approved but cannot get verified by the backend. Since the alpha track is a productive enviroment, we do not have the console or network logs to check whats the problem. What is the best practice here. Is there a way to debug verification ?
In my case the problem is insufficent permission of my Google Client. I used the tokens which we got from the productive enviroment and used them in the local api.
I have multiple subscriptions to different entities, and at some random time one of the subscriptions stops being notified.
This is because the lastNotification attribute is set in the future. Here is an example :
curl 'http://localhost:1026/v2/subscriptions/xxxxxxxxxxxxxxx'
{
"id": "xxxxxxxxxxxxxxx",
...
"status": "active",
...
"notification": {
"timesSent": 1316413,
"lastNotification": "2021-01-20T18:33:39.000Z",
...
"lastFailure": "2021-01-18T12:11:26.000Z",
"lastFailureReason": "Timeout was reached",
"lastSuccess": "2021-01-20T17:12:09.000Z",
"lastSuccessCode": 204
}
}
In this example, lastNotification is ahead of time. It is not until 2021-01-20T18: 33: 39.000Z for the subscription to be notified again.
I tried to modify lastNotification in the mongo database but that does not change it. Looks like the value 2021-01-20T18: 33: 39.000Z is cached.
The field lastFailureReason specifies the reason of the last notification failure associated to that subscription. The diagnose notification reception problems section in the documentation explains possible causes for "Timeout was reached". It makes sense to have this fail randomly if your network connection is somehow unstable.
With regards to timestamping in the future (no matter if it happens for lastNotification, lastFailure or lastSuccess) is pretty weird and probably not associated to Orion Context Broker operation. Orion takes timestamp from internal clock of the system where it is running, so maybe your system clock is set in the future.
Except if you run Orion Context Broker with -noCache (which in general is not recommended), subscriptions are cached. Thus, if you "hack" them in the DB you will not see the effect until next cache refresh (refreshes takes place at regular intervals, defined by -subCacheIval parameter).
I'm unable to access the education/users endpoint but I am able to access other endpoints (education/classes, education/schools).
Whenever I try to get a list of all users, I get the following error:
{
"error": {
"code": "AccessDenied",
"message": "Required claim values are not provided.",
"innerError": {
"request-id": "58c42204-440a-482c-b1e9-4c65bb413ed1",
"date": "2018-03-21T20:23:24"
}
}
}
When I try to make the call using the Graph Explorer, I'm given the following notice:
Failure - Status Code - Looks like you may not have the permissions for this call. Please modify your permissions.
Unfortunately, I get the same error after modifying my permissions.
If anyone has any idea why this might be happening, I would be very grateful for the help.
For app+user (delegate) permissions, the only supported scope for the /education/users collection on MSGraph is EduRoster.ReadBasic.
This supports getting an individual user's information, or information on lists of users within classes of which you are a member, but does NOT support browsing the entire set of users in a tenant, as it is deliberately a restricted scope.
If you need more than this, you would need to use app-only permissions, and sync the users into your own data store with EduRoster.Read.All, which would allow you to get all of the users.
I have setup sensu-server and client successfully and all is working except one thing . in this image
you can see that there are alerts for mysql and web ports.but I have given only "mysql" subscription right now in my client.json file in my client system. I have removed the "webserver" subscription from client.json (which I added initially before replacing it with "mysql" ) but still the checks associated with the "webserver" subscription are displayed. why is this? and how to display only the checks associated with the given subcription. here is my client.json
{
"client": {
"name": "sensuclient2",
"address": "127.0.0.1",
"keepalive": {
"thresholds": {
"warning": 60,
"critical": 120
},
"handlers": ["default", "mailer", "sns"]
},
"subscriptions": [
"mysql"
]
}
}
It's possible Uchiwa is showing older checks, prior to the change you made to your client configuration file (at least I went through that once!). Try deleting the events. If the API is not running the checks anymore, the events won't come up again.
You can either use sensu-cli to delete the events:
sensu-cli event delete sensuclient2 check_http
https://github.com/agent462/sensu-cli
Or make an API call...
curl -s -i -X DELETE http://yourhost:yourport/events/sensuclient2/check_http
https://sensuapp.org/docs/1.1/api/events-api.html#eventsclientcheck-delete
If the checks do come back you should check both server and and client side checks and client configuration.
Also, the simplest is the best, #vishal.k himself reminded me:
you can always delete the events using Uchiwa's interface. :)
I have a web app using Google Custom Search via REST. So far, everything works fine, but when I exceed the allotted daily quota of queries, I want to give the user some info about it. I get this JSON response, and I can access the "code" and "message" data using response.error.code and response.error.message, but I don´t know how to access the subset "errors", specifically "reason".
I know this is a JSON question, but I don´t have much experience with it.
This is the JSON structure I receive (which is what I expect)
{
"error": {
"errors": [
{
"domain": "usageLimits",
"reason": "dailyLimitExceeded",
"message": "This API requires billing to be enabled on the project. Visit https://console.developers.google.com/billing?project=323544036192 to enable billing.",
"extendedHelp": "https://console.developers.google.com/billing?project=323544036192"
}
],
"code": 403,
"message": "This API requires billing to be enabled on the project. Visit https://console.developers.google.com/billing?project=323544036192 to enable billing."
}
}
I found the solution trying different things. I think I got lucky.
console.log(response.error.errors[0].reason);
This gives me the data I was trying to access.