I'm trying to pull down the full state of group membership via the directory API, and since the members.list(groupKey=group_email) call won't return delivery_settings in its response, I'm stuck walking the list of group members and doing a members.get(groupKey=group_email, memberKey=member_email) call for each member. I'm regularly seeing some of those get() calls fail with a 404 "Resource Not Found: email" error.
The error reproduces in the API explorer, and is reliably reproducible (if I see an error for a particular group/member combo running my script, the API explorer will show the same error). I can't find anything that the bad group/members have in common that's unique to just those members.
As a workaround, I've found that grabbing the id field from the members.list() response, and turning my get() call into members.get(groupKey=group_address, memberKey=id) will work. Does anyone have any idea why an email memberKey would fail, but the id wouldnt?
After getting in touch with Google support, it turns out this is a known issue, but no current eta for a fix. We're expected to work around it by using the membership id instead of the email address as the memberKey.
Related
I try to get return report from amazon, but my request is always cancelled. I have working request report using
'ReportType' => 'GET_MERCHANT_LISTINGS_DATA',
'ReportOptions' => 'ShowSalesChannel=true'
I modify it by changing ReportType and removing ReportOptions. MWS accept request by its always cancelled. I also try to find any working example of it on google but also without success. Meybe somone have working example of it? I can downolad report when I send request from amazon webpage. I suppose it require ReportOptions, but I dont know what to put in this place (I have only info ReportProcessingStatus CANCELLED). Normally I choose Day,Week,Month. I check on amazon docs but there isnt many informations https://docs.developer.amazonservices.com/en_US/reports/Reports_RequestReport.html
Any ideas?
We are seeing a random error that seems to be caused by two requests' data getting mixed up. We receive a request for quoting shipping costs on an Order, but the request fails because the requested Order is not accessible by the requesting account. I'm looking for anyone who can provide an inkling on what might be happening here, I haven't found anything on google, the official flask help channels, or SO that looks like what we're experiencing.
We're deployed on AWS, with apache, mod_wsgi, 1 process, 15 threads, about 10 instances.
Here's the code that sends the email:
msg = f"Order ID {self.shipping.order.id} is not valid for this Account {self.user.account_id}"
body = f"Error:<br/>{msg}<br/>Request Data:<br/>{request.data}<br/>Headers:<br/>{request.headers}"
send_email(msg, body, "devops#*******.com")
request_data = None
The problem is that in that scenario we email ourselves with the error and the request data, and the request data we're getting, in many cases, would've never landed in that particular piece of code. It can be a request from the frontend to get the current user's settings, for example, that make no reference to any orders, nevermind trying to get a shipping quote for it.
Comparing the application logs with apache's access_log, we see that, in all cases, we got two requests on the same instance, one requesting the quoting, and another which is the request that is actually getting logged. We don't know whether these two requests are processed by the same thread in rapid succession, or by different threads, but they come so close together that I think the latter is much more probable. We have no way of univocally tying the access_log entries with the application logging, so far, so we don't know which one of the requests is logging the error, but the fact is that we're getting routed to a view that does not correspond to the request's content (i.e., we're not sure whether the quoting request is getting the wrong request object, or if the other one is getting routed to the wrong view).
Another fact that is of interest is that we use graphql, so part of the routing is done after flask/werkzeug do theirs, but the body we get from flask.request at the moment the error shows up does not correspond with the graphql function/mutation that gets executed. But this also happens in views mapped directly through flask. The user is looked up by the flask-login workflow at the very beginning, and it corresponds to the "bad" request (i.e., the one not for quoting).
The actual issue was a bug on one of python-graphql's libraries (promise), not on Flask, werkzeug or apache. It was not the request data that was "moving" to a different thread, but a different thread trying to resolve the promise for a query that was supposed to be handled elsewhere.
we already have a release version in playstore and its working just fine.
But suddenly now when we try to build and run the code again since we want to add new functionality. It would no longer communicate with our backend.
So i searched the net using the error as keyword and saw that need INTERNET PERMISSION as the 100% result and answer, which we have already and not helpful at all. Yes we have it in debug and live manifests.
The server is up we can access it in the browser and as well as postman also dig command
So i searched more things in the net to no avail, found about the because proxy issue thing i tried both client side and server-side. we don't have proxy
we use simple request only like this:
static Future getDriver(String phone){
var url = baseUrl + "/mobile/driverPhone";
return http.post(url,body: {
"phone" : phone
});
}
also some suggestion say to use DIO, but i want to know the reason first before i gave up with this http plugin. Can someone with good heart explain and help me with this?
P.S. we on master channel, here are some error logs
The error SocketException: Failed host lookup: 'api.xyz.com' (OS Error: No address associated with hostname, errno = 7) usually means that your DNS lookup fails. From the error itself OS Error, is usually a system-level error and nothing specific to http or Dart/Flutter.
You might need to adjust some settings in your DNS. Also, if you are using a Mac/Linux system you might be able to run dig api.xyz.com to see if that resolves.
Running your app in the actual device could be possible as well since there is a possibility its getting an error in your virtual device due to DNS settings or the virtual device you are using is not connected to the internet. You will be able to isolate the problem.
I have a simple service (C# web service) that accepts an integer and returns an integer, i have tested it using Storm it is working properly.
Now i am calling this service in a for loop in a file with around 2000 records approx, this service is failing giving the above error with some records. If i run the error file it goes through as if nothing was wrong, what might be the problem please help.
The error doesn't seem related to it being a web service call: it seems to indicate you either tried to GetEntity and passed in a zero/NullIdentifier() (not a valid Id), or maybe you tried an CreateEntity and that entity has a foreign key that is not filled in (i.e. zero/NullIdentifier() again).
I would start by checking the logic inside the WS method for those action calls and the inputs you are using there.
I had code that was working that would create a new platform application for every message that went out. I thought that was wasteful so I tried to change the code to use list_platform_applications to get available applications and reuse the one that has the proper name (part of the PlatformApplicationArn).
This will work for several messages in a row when suddenly I'll get this error from CreatePlatformApplication:
{"Error":{"Code":"InvalidParameter","Message":"Invalid parameter: This
endpoint is already registered with a different
token.","Type":"Sender"},"RequestId":"06bd3443-598e-5c06-9f5c-7f84349ea067"}
That doesn't even make sense. I'm creating an endpoint. I didn't pass one in. Is it really complaining about the endpoint it's returning.
According to the Amazon documentation:
"The CreatePlatformEndpoint action is idempotent, so if the requester
already owns an endpoint with the same device token and attributes,
that endpoint's ARN is returned without creating a new endpoint."
So it seems to me, if there's an appropriate one it will be returned. Otherwise, create a brand new fresh one.
Am I missing something?
Oh darn. I think I found the reason for this behavior. After facing this issue, I made sure that each token was only uploaded once to AWS SNS. When testing this, I realized that nevertheless I ended up with multiple endpoints with the same token - huh???
It turned out that these duplicated tokens resulted from outdated tokens being uploaded to AWS SNS. After creating an endpoint using an outdated token, SNS would automagically revive the endpoint by updating it with the current device token (which afaik is delivered back from GCM as a canonical ID once you try to send push messages to outdated tokens).
So e.g. uploading these (made-up) tokens and custom data
APA9...YFDw, {original_token: APA9...YFDw}
APA9...XaSd, {original_token: APA9...XaSd} <-- Assume this token is outdated
APA9...sVQa, {original_token: APA9...sVQa}
might result in something like this - i.e. different endpoints with identical tokens:
APA9...YFDw, {original_token: APA9...YFDw}, arn:aws:sns:eu-west-1:4711:endpoint/GCM/myapp/daf64...5c204
APA9...YFDw, {original_token: APA9...XaSd}, arn:aws:sns:eu-west-1:4711:endpoint/GCM/myapp/a980f...e3c82 <-- Duplicate token!
APA9...sVQa, {original_token: APA9...sVQa}, arn:aws:sns:eu-west-1:4711:endpoint/GCM/myapp/14777...7d9ff
This scenario in turn seems to lead to above error on subsequent attempts to create endpoints using outdated tokens. On the hand, it seems correct that subsequent requests fail. On the other hand, intuitively I have the gut-feeling that the duplication of tokens that is taking place seems wrong, or at least difficult to handle. Maybe once SNS discovers that a token is outdated and needs to be changed, it could first check if there is already another endpoint existent with the same token...
I will research on this a bit more and see if I can find a way to handle this properly.
Cheers
Had the same issue, with the device reporting one token (outdated according to GCM) and the SNS retrieving/storing another.
We solved it by clearing the app cache on the device and reopening the app (which in our case, re-registered the device on the gcm service), generating the same token (not outdated) that SNS was attempting to push to.