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.

Sign up for GitHub

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

Jump to bottom

makeHealthEntry fails in portal-api if external apiHost points to other location #95

Closed
DonMartin76 opened this issue Dec 14, 2017 · 1 comment
Closed

makeHealthEntry fails in portal-api if external apiHost points to other location #95

DonMartin76 opened this issue Dec 14, 2017 · 1 comment
Labels
bug
Milestone
0.12.3

Comments

@DonMartin76
Copy link
Member

In the following situation, you will end up with a wicked portal-api container which is not stable:

  • Imagine you are deploying a new infrastructure which will replace (by DNS switch) an old installation
  • During startup, everything is running in a non-exposed way, i.e. the FQDN which is stated in the globals.json is not (yet) valid
  • If the old DNS entry now points to something which actually responds, and does NOT respond with a JSON (but e.g. with an HTML page), the health check will fail like this:
Thu, 14 Dec 2017 10:39:39 GMT portal-api:webhooks loadEvents(): kong-adapter
Thu, 14 Dec 2017 10:39:39 GMT portal-api:systemhealth makeHealthEntry()
undefined:1
<!DOCTYPE html>
^

SyntaxError: Unexpected token < in JSON at position 0
    at Object.parse (native)
    at Function.utils.getJson (/usr/src/app/routes/utils.js:35:21)
    at makeHealthEntry (/usr/src/app/routes/systemhealth.js:195:30)
    at Request._callback (/usr/src/app/routes/systemhealth.js:70:32)
    at Request.self.callback (/usr/src/app/node_modules/request/request.js:187:22)
    at emitTwo (events.js:106:13)
    at Request.emit (events.js:191:7)
    at Request.<anonymous> (/usr/src/app/node_modules/request/request.js:1044:10)
    at emitOne (events.js:96:13)
    at Request.emit (events.js:188:7)

Possible fixes:

  • Do not use the external FQDN apiHost, but the internal port of the Kong Gateway to retrieve the /ping-portal response (to see whether Kong is correctly wired)
  • (Additionally) wrap the getJson(apiResponse) in a try-catch block to make sure it never completely crashes the application (in systemhealth.js: makeHealthEntry()):
    var pingResponse = utils.getJson(apiBody);

This line causes the issue.
@DonMartin76 DonMartin76 added this to the 0.12.3 milestone Dec 14, 2017
@DonMartin76
Copy link
Member Author

Fixed in 0.12.3/4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
0.12.3
Development

No branches or pull requests
1 participant
@DonMartin76