Add sane error message for unreachable host

[Redsandro]

najax: method jqXHR."getAllResponseHeaders" not implemented

Update

I'm observing the following error every time my fastboot ember app goes to a route with this.store.query():

najax: method jqXHR."getAllResponseHeaders" not implemented
[object Object]
    at Object.getAllResponseHeaders (/www/node_modules/najax/lib/najax.js:108:15)
    at ajaxResponseData (/www/tmp/broccoli_merge_trees-output_path-xxExqEhS.tmp/assets/addon-tree-output/ember-data/adapters/rest.js:1116:1)
    at ajaxErrorHandler (/www/tmp/broccoli_merge_trees-output_path-xxExqEhS.tmp/assets/addon-tree-output/ember-data/adapters/rest.js:1106:1)
    at Object.hash.error (/www/tmp/broccoli_merge_trees-output_path-xxExqEhS.tmp/assets/addon-tree-output/ember-data/adapters/rest.js:877:1)
    at fire (/www/node_modules/jquery-deferred/lib/jquery-callbacks.js:78:30)
    at Object.fireWith (/www/node_modules/jquery-deferred/lib/jquery-callbacks.js:188:7)
    at Object.fire [as reject] (/www/node_modules/jquery-deferred/lib/jquery-callbacks.js:195:10)
    at ClientRequest.onError (/www/node_modules/najax/lib/najax.js:208:9)
    at emitOne (events.js:116:13)
    at ClientRequest.emit (events.js:211:7)

On routes with multiple queries, I'm observing this message many times. It is flooding my logs.

The routes seem to work because Fastboot returns a non-fastboot page, which works.

This happens when the domain can be reached from the client, but cannot be reached from the Fastboot server.

Please add a more sane error message, as this makes it seem like the response is fine but something is wrong with the najax library.

---

Looks like this issue:

@kedano commented on Mar 3, 2016:

ember serve works just fine on the project and it looks like ember fastboot almost works as well except for one issue:

najax: method jqXHR."getAllResponseHeaders" not implemented

Except that issue was fixed ~~five hundred~~ two years ago. The current issue has a different cause.

---

$ cat node_modules/ember-cli-fastboot/package.json | grep \"version\":
  "version": "1.1.4-beta.1"

$ ./node_modules/.bin/ember version --verbose
ember-cli: 3.3.0
http_parser: 2.8.0
node: 8.12.0
v8: 6.2.414.66
uv: 1.19.2
zlib: 1.2.11
ares: 1.10.1-DEV
modules: 57
nghttp2: 1.32.0
napi: 3
openssl: 1.0.2p
icu: 60.1
unicode: 10.0
cldr: 32.0
tz: 2017c
os: linux x64

[ChristopheVandePoel]

I started getting the same error not so long ago. It happens on my VM, but not when I run it straight from my wsl console locally.

Internally, there's a getaddrinfo EAI_AGAIN error that results in a getAllResponseHeaders call that fails. For me at least, it was caused by running on a VM that was named in my host-machine's host-file, but not internally in the VM itself. So adding this line to the VM's /etc/hosts file resolved the issue:

127.0.0.1       localhost.localdomain   localhost
::1             localhost6.localdomain6 localhost6
127.0.0.1       localhost.localdomain   your-custom-name-here   <- this one

[Redsandro]

@ChristopheVandePoel I figured out this error happens (in my case at least) when the host cannot be found from the fastboot server.

I was attaching a network to the client which was unreachable on the Ember Fastboot server. It worked, because it was reachable on the client, and fastboot returned a non-fastboot page.

This happens for example on certain Vagrant or Docker setups, when the datastore API has a port that is not shared on the internal network due to a Firewall or (lack of) exposed ports, but is available on the client outside the Vagrant/Docker environment, causing the non-fastboot page to load from the Datastore successfully.

Considerable time was wasted on figuring this problem out. The error messages made me believe that a response was received, but some kind of feature was not implemented.

Fastboot should return a more sane error message when the host does not exist.

[ChristopheVandePoel]

@Redsandro sorry that it wasn't too clear by the explanation, but that was exactly the problem. Because my VM host-file was not configured to match the dev domain back to itself, it could not find it. (I prefer a readable, constant name for my VM in stead of an IP). And I came to the same conclusion that fastboot might try to give better errors. Because it was catching that getaddrinfo EAI_AGAIN error error that led me to the solution. That information would have been useful the 3 hours preceding it, trying to find it. :)

[Redsandro]

I've run into the same problem because after 6 months apparently I forget things. :sweat_smile: I could have wasted less time if the actual problem would have a sane error message.

web_1    | najax: method jqXHR."getAllResponseHeaders" not implemented
web_1    | [object Object]
web_1    |     at Object.getAllResponseHeaders (/app/node_modules/najax/lib/najax.js:108:15)
web_1    |     at ajaxResponseData (/tmp/broccoli-16muhuEbMsaNDx/out-326-broccoli_merge_trees/assets/addon-tree-output/ember-data/adapters/rest.js:1146:1)
web_1    |     at ajaxErrorHandler (/tmp/broccoli-16muhuEbMsaNDx/out-326-broccoli_merge_trees/assets/addon-tree-output/ember-data/adapters/rest.js:1136:1)
web_1    |     at Object.hash.error (/tmp/broccoli-16muhuEbMsaNDx/out-326-broccoli_merge_trees/assets/addon-tree-output/ember-data/adapters/rest.js:884:1)
web_1    |     at fire (/app/node_modules/jquery-deferred/lib/jquery-callbacks.js:78:30)
web_1    |     at Object.fireWith (/app/node_modules/jquery-deferred/lib/jquery-callbacks.js:188:7)
web_1    |     at Object.fire [as reject] (/app/node_modules/jquery-deferred/lib/jquery-callbacks.js:195:10)
web_1    |     at ClientRequest.onError (/app/node_modules/najax/lib/najax.js:208:9)
web_1    |     at emitOne (events.js:116:13)
web_1    |     at ClientRequest.emit (events.js:211:7)

Most of the nAjax stuff was written by @danmcclain over 3 years ago. Any thoughts on this issue?

[eduscrakozabrus]

localhost.localdomain !!!add your.domain.com&api!!!

this is solution is worked!

[Redsandro]

One of my old apps started doing this again some months ago. The error is slightly different down the line (l.error in stead of hash.error)

web_1    | najax: method jqXHR."getAllResponseHeaders" not implemented
web_1    | [object Object]
web_1    |     at Object.getAllResponseHeaders (/app/node_modules/najax/lib/najax.js:108:15)
web_1    |     at o (/app/dist/assets/vendor-6fb104c69d3823c54d8e8e6288be4613.js:15213:99)
web_1    |     at /app/dist/assets/vendor-6fb104c69d3823c54d8e8e6288be4613.js:15187:55
web_1    |     at Object.l.error (/app/dist/assets/vendor-6fb104c69d3823c54d8e8e6288be4613.js:15194:100)
web_1    |     at fire (/app/node_modules/jquery-deferred/lib/jquery-callbacks.js:78:30)
web_1    |     at Object.fireWith (/app/node_modules/jquery-deferred/lib/jquery-callbacks.js:188:7)
web_1    |     at Object.fire [as reject] (/app/node_modules/jquery-deferred/lib/jquery-callbacks.js:195:10)
web_1    |     at ClientRequest.onError (/app/node_modules/najax/lib/najax.js:208:9)
web_1    |     at emitOne (events.js:116:13)
web_1    |     at ClientRequest.emit (events.js:211:7)

This time though, I checked to make sure that the fastboot server can reach the requested url.

I've only had a few reports so it's hard to pinpoint exactly when this started happening, but it's plausible that it has something to do with the DST Root CA X3 Expiration (September 2021) since the app went unmaintained since the end of 2020 and back then it still worked.

On the other hand, you would expect this dirty trick to work in the Fastboot Dockerfile, but it did not:

ENV NODE_TLS_REJECT_UNAUTHORIZED=0
CMD env NODE_TLS_REJECT_UNAUTHORIZED=0 node server.js

Ember and Fastboot have come a long way since then. Does anyone know/remember if this or what else could affect a Fastboot server like that back then?