Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mustache_unescape error on some clustered setups #360

Closed
djphan opened this issue Apr 21, 2017 · 2 comments
Closed

mustache_unescape error on some clustered setups #360

djphan opened this issue Apr 21, 2017 · 2 comments
Milestone

Comments

@djphan
Copy link

djphan commented Apr 21, 2017

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 GUI added this to the v0.14.1 milestone Apr 22, 2017
@GUI
Copy link
Member

GUI commented Apr 22, 2017

@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 added a commit that referenced this issue Apr 22, 2017
See #360

If the frontend or backend fields were left empty, then various things
could break. This fixes it via a few different means:

- Adding validations to the models to ensure these fields get filled
  out.
- Handle the possibility of these fields being empty within the proxy
  code (so bad configs that already in the database are ignored).
- More generally, wrap the config loading logic in the proxy layer in
  more error handling, so if unexpected errors occur, they just impact
  that single API, rather than preventing all API config from loading.
GUI added a commit that referenced this issue Apr 23, 2017
Similar to issue for rewrites in
#360

Add missing validations for the regex field, and update proxy to deal
more gracefully with any existing backends where this is missing.
@GUI
Copy link
Member

GUI commented Apr 24, 2017

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!

@GUI GUI closed this as completed Apr 24, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants