Getting error on every other call to my a127-based API ...

[#1]

This particular a127-based API worked fine from our Apigee Edge deployment when I ran it on Friday but now doesn't seem to work. The odd thing is that it is failing every other time.

When I use a RemoteProxy to run this API locally, it works everytime.

At first I suspected caching but the failure is happening on API paths that don't have caching enabled.

I also get an error when I go to the ApigeeEdge dev portal to look at the node logs. When i do, I get the following error: "There was an error while retrieving Node.js logs for this proxy."

Please let me know if I can supply anything to help trouble shoot this problem.

NOTE: I just had someone check the logs of the system that the node API targets and it looks like the error is occurring before we call out to the backend system so maybe its happening before we even get the the controllers massage handler. This behavior happens on all of the API paths on that API. It also seems to be consistently happening every other time the API is called..

Thanks!

...Ed

P.S. The error I get back when I execute my API from postman, is the following:

{
"fault": {
"faultstring": "Script node executed prematurely: TypeError: Cannot find function captureStackTrace in object function Error() { [native code for Error.Error, arity=1] }\ .\ \	at \/organization\/environment\/api\/node_modules\/a127-magic\/node_modules\/swagger-tools\/node_modules\/serve-static\/node_modules\/send\/node_modules\/depd\/lib\/compat\/index.js:28 (callSiteToString)\ \	at \/organization\/environment\/api\/node_modules\/a127-magic\/node_modules\/swagger-tools\/node_modules\/serve-static\/node_modules\/send\/node_modules\/depd\/lib\/compat\/index.js:45 (get)\ \	at \/organization\/environment\/api\/node_modules\/a127-magic\/node_modules\/swagger-tools\/node_modules\/serve-static\/node_modules\/send\/node_modules\/depd\/index.js:11 (anonymous)\ \	at module.js:456 (anonymous)\ \	at module.js:474 (anonymous)\ \	at module.js:356 (anonymous)\ \	at module.js:312 (anonymous)\ \	at module.js:364 (anonymous)\ \	at module.js:380 (require)\ \	at \/organization\/environment\/api\/node_modules\/express\/lib\/express.js:5 (anonymous)\ \	at module.js:456 (anonymous)\ \	at module.js:474 (anonymous)\ \	at module.js:356 (anonymous)\ \	at module.js:312 (anonymous)\ \	at module.js:364 (anonymous)\ \	at module.js:380 (require)\ \	at \/organization\/environment\/api\/node_modules\/express\/index.js:2 (anonymous)\ \	at module.js:456 (anonymous)\ \	at module.js:474 (anonymous)\ \	at module.js:356 (anonymous)\ \	at module.js:312 (anonymous)\ \	at module.js:364 (anonymous)\ \	at module.js:380 (require)\ \	at \/organization\/environment\/api\/app.js:4 (anonymous)\ \	at module.js:456 (anonymous)\ \	at module.js:474 (anonymous)\ \	at module.js:356 (anonymous)\ \	at module.js:312 (anonymous)\ \	at module.js:497 (anonymous)\ \	at trireme.js:142 (startup)\ \	at trireme.js:923 (anonymous)\ ",
"detail": {
"errorcode": "scripts.node.runtime.ScriptExitedError"
}
}
}

[willwitman]

Ed, This is a shot in the dark, but did you use the -u option when you deployed your project (e.g., a127 project deploy -u)? This uploads all the node dependencies from your local machine rather than relying on Edge to resolve them on the server.

[#3]

Thanks Will, I will try this out tomorrow when I'm in the office. This does bring up a question I ha on deployment:

When should I be be using the -u option?

I guess I'm concerned that I might be in a catch 22 ... if ApigeeEdge changes how it interacts with a127 then my APIs could break if I use the -u options, but if I don't use the -u option, then my app could be working then all of a sudden break when/if these dependencies get updated in ApigeeEdge.

I think I need to better understand or have some guidance about when/how I should be deplying.

[#4]

Hi Will,

I actually didn't need to redeploy using -u, it just started working this morning when I tried it. I think I will leave well enough alone.

I wonder if something was done on the Apigee Edge side of things.

I will post my other questions regarding when to use -u and guidance around deployment to another question thread to give others a chance to chime in as well as provide a question that others can reference.

Thanks again for your help.

...Ed

[willwitman]

Hi Ed,

I don't think I was on track with the -u option -- there was a problem a few months ago with deploying, which was resolved partly by adding the -u option to a127. But I don't think that's the cause of this problem. There's no guidance one way or the other -- AFAIK, things should work with or without -u.

[#6]

I had this same issue and adding the "-u" option fixed it! Thank you for your help!

[#7 · Accepted solution]

Ed, can you please confirm this issue is resolved for you? We may have had some loose ends that needed tightening

[#8]

No problem Kris, I am going to try out Will's suggestion tomorrow when I am in the office.

I want to pose the same question to you as a posed to Will above:

Is there any guidance that can be offered regarding how we should be deploying (-u or no -u?) Also maybe some guidance on how to handle dependencies. I don't think I have very unusual dependencies which is why I'm concerned.

I'm also concerned that I was getting errors when trying to look at the node logs for this API.

Thanks for helping me understand ... I must say, I am very impressed with the level of support I've gotten on this dev account ... THANKS!

[#9]

Hi Kris,

It looks like everything works now. I am also able to get into the node logs. I assume this was a result of a fix made on the Apigee Edge side since I did not change anything on my side.

Thanks for getting this working!

...Ed

[#10]

Ed,

Anytime I see failure in a pattern I start to look at the state of my nodes. If your running on multiple MPs it may be that one of them has an issue, anything from a fault in the underlying platform to a missing entry for an MP on a whitelist protected target.

The above pointers are a great start, but also do a quick check of your MPs and ensure your targets are reachable from all of your MPs.

[#11]

Thanks David. I actually didn't change anything or redeloy and now it all seems to be working. I think there must have been something that changed in ApigeeEdge.

[#12]

Ed, we restarted your Apigee Message Processor yesterday and were hoping it may have resolved your issue

[#13]

It definitely did the trick. Thanks Kris!

[#14]

Similar error just occurred (Aug 2015) for me and I resolved via -u flag but not sure where to report this for Apigee to resolve within their systems.