search

NREL / api-umbrella

Open source API management platform
http://apiumbrella.io
MIT License
2.02k stars 324 forks source link

mustache_unescape error on some clustered setups #360

Closed djphan closed 7 years ago

djphan commented 7 years ago

Hi GUI,

I've ran into an odd issue where some of my VMs running the proxy hit this error in the nginx logs: 2017-04-21T17:14:14.16130 2017/04/21 10:14:14 [error] 22924#0: [lua] interval_lock.lua:41: timeout_exec(): timeout exec pcall failed: .../current/src/api-umbrella/proxy/models/active_config.lua:82: bad argument #1 to 'mustache_unescape' (string expected, got nil), context: ngx.timer

My proxy service is failing, and I get a 404 nginx page going to my configured url in the proxy. The admin panel sometimes is accessible, but some of my nodes throws an emberJS error.

I have a multi node setup with a separate install of mongoDB. I do not see any obvious errors being thrown in mongo or elastic search, and have checked that they were running fine. I copied my config to another VM for additional testing and the proxy ran fine. But I have a few clusters that are running into the above error.

GUI commented 7 years ago

@djphan: It looks like this may happen if you add an item to the "Advanced Requests Rewriting" section of an API Backend, but don't fill in the "Backend Replacement" field. But how this impacts the server is pretty nasty (since it might make the server incapable of serving requests after the server is restarted), so apologies for the bug! We'll get this patched in the next release we're hoping to get out soon.

But if you're looking for a quick fix on your existing servers, here's how you can manually patch your server to workaround this issue: In /opt/api-umbrella/embedded/apps/core/current/src/api-umbrella/proxy/models/active_config.lua, you'll find this code on line 81:

      if rewrite["matcher_type"] == "route" then

Replace that with:

      if rewrite["matcher_type"] == "route" and rewrite["frontend_matcher"] and rewrite["backend_replacement"] then

And then restart API Umbrella (sudo /etc/init.d/api-umbrella restart). That should at least get you back in action.

We'll implement more error handling and validation around these fields in the upcoming release. Thanks for reporting the issue!.

GUI commented 7 years ago

v0.14.1 has been released with this fix in it. I also discovered a similar issue could happen if you didn't fill out the "regex" field in the API sub-settings area. That's also been fixed in v0.14.1. Thanks again for reporting this issue!