Apigee apis not returning valid response
Apigee apis sometimes are not returning valid response. My target api return 204 response. For this api apigee sometimes return 200 & sometimes 204 as response code and this api is being traced only when I get 204 response code. When I get 200 then api is not being traced in trace tool.
Hi, thanks for your comment.
Do you have a question?
If so, please be explicit and specific when you state the question.
And you'll need to provide some clear evidence; screenshots of the trace screen, etc.
Apigee should return 204 response and I am able to trace this in tracing tool. But sometime this api returns 200 response and at that time api is not being traced.
Please find attached snapshot for same
Answer by Dino-at-Google
·
Feb 07 at 09:54 PM
Hi Thanks for the question and the screenshots.
I don't know what's happening - it's a puzzle. It's hard to know what is happening from the information you've given.
But, I can offer some observations, ideas, and questions.
- Sometimes it takes some time for a transaction to appear in the Trace UI, after it has been executed. Your client may "see" the response before the Trace UI will display the transaction. Sometimes you may have to wait 3-5 seconds or more before the transaction appears. So, are you sure that the 200 response NEVER appears?
- I have never seen the case in which the Apigee Edge trace UI does not capture transactions that are legitimately flowing through the traced Apigee Edge proxy. I'm not saying that it's impossible for a bug to have occurred within Apigee Edge to cause a transaction to be dropped from Trace even though it is being handled by the gateway; I am saying that it seems highly unlikely.
- Are you sure that the proxy you are tracing will receive all requests that you send from Postman (or your rest client, whatever it is)? With Apigee Edge, it is possible to create multiple API proxies, that listen at various base paths. It is possible, then, for a proxy to listen at / , which would then intercept ALL inbound calls. That proxy could then... randomly forward some requests to the InspectionApi proxy, and not forward others. Is it possible that is happening here?
- The postman client is showing 17 respond headers in one case, and 6 in the other. Why the difference?
- Why does your service sometimes return 200 and sometimes 204? Are you TRYING to produce a service that does this? Is this expected and desired? Or is this just something you're trying in development? If the latter, are you saying that NO 200 response is EVER traced? That's extraordinary.
I'm interested in hearing more.
I am just hitting same request multiple times. Sometimes I am getting 204 (which is expected response and this is also being traced) and sometimes I am getting 200 (which is not expected and this is not being traced) with response body same as request body.
I am not sure if header will make any difference. Below is list of headers.
For 204 postman is sending 6 header :
connection →keep-alive
content-length →0
content-type →application/json;charset=UTF-8
date →Fri, 08 Feb 2019 05:43:09 GMT
server →Apache
x-cub-hdr →{"result":"Successful","uid":"a980836f-aa37-460c-b779-4d01e67bd259"}
For 200 postman is sending 17 headers :
accept →*/*
accept-encoding →gzip, deflate, br
accept-language →en-GB,en-US;q=0.9,en;q=0.8
authorization →Basic d2ViOnBhc3N3b3Jk
cache-control →no-cache
connection →keep-alive
content-length →37
content-type →text/plain;charset=UTF-8
date →Fri, 08 Feb 2019 05:49:17 GMT
host →cubictrial-test.apigee.net
origin →chrome-extension://fhbjgbiflinjbdggehcddcbncdddomop
postman-token →2a7ff215-d92a-7c23-bdd2-3c832c75dd9c
user-agent →Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
x-cub-hdr →{"uid":"9cf73f39-2b8f-47cd-8b59-9abe8f1ef6ef","device":"NIS","appId":"NIS"}
x-forwarded-for →13.127.155.195
x-forwarded-port →443
x-forwarded-proto →https
