Impression events don't respect HTTPS_PROXY #122
Comments
|
Hi! Thanks for the feedback! We try to make very few assumptions about the environment that the SDK runs on and instead make it easy for the SDK to be configured to fit in where it is used. The issue you describe has to do with our out of the box event dispatcher. What you can do is to override the event dispatcher as described here: https://developers.optimizely.com/x/solutions/sdks/reference/?language=javascript#event-dispatcher I've dug up our old event dispatcher, which uses the |
|
Thanks for the workaround, we'll try implementing that in our development environments. However, The more important issue here is probably that the default event dispatcher throws an uncatchable exception and crashes the application server. This will occur whenever/if optimizely is unavailable for any reason (i.e. Blocked by a proxy, or some actual downtime) which should probably be fixed regardless. |
|
👍 we will look into it on our end, thanks! |
|
I think what may be happening is that
(via https://nodejs.org/api/events.html#events_error_events) So we should add an error handler immediately after requesting to catch+log any error that might have occurred. |
|
Once again, thanks @Geit for reporting this! We'll make sure to prevent the crashing, but won't be adding proxy support at this time. As we noted, you can use a custom event dispatcher to address that issue. |
- (nodejs) Prevent crash when `http`/`https` emits an error by adding an 'error' listener - (nodejs) Fix `requestCallback` to conform to its role as a 'response' listener; notably, ensure it is called when the first argument is interpeted as the `http.IncomingMessage`, and _not_ called in the event of an error (as expected by `Optimizely#_sendImpressionEvent`/`Optimizely#track`). Tested that this version (as 2.1.2-0) _does_ emit the messages expected in the demo app. Fixes #122 Fixes #124
- (nodejs) Prevent crash when `http`/`https` emits an error by adding an 'error' listener - (nodejs) Fix `requestCallback` to conform to its role as a 'response' listener; notably, ensure it is called when the first argument is interpeted as the `http.IncomingMessage`, and _not_ called in the event of an error (as expected by `Optimizely#_sendImpressionEvent`/`Optimizely#track`). Tested that this version (as 2.1.2-0) _does_ emit the messages expected in the demo app. Fixes #122 Fixes #124
- (nodejs) Prevent crash when `http`/`https` emits an error by adding an 'error' listener - (nodejs) Fix `requestCallback` to conform to its role as a 'response' listener; notably, ensure it is called when the first argument is interpeted as the `http.IncomingMessage`, and _not_ called in the event of an error (as expected by `Optimizely#_sendImpressionEvent`/`Optimizely#track`). Tested that this version (as 2.1.2-0) _does_ emit the messages expected in the demo app. Fixes #122 Fixes #124
- (nodejs) Prevent crash when `http`/`https` emits an error by adding an 'error' listener - (nodejs) Fix `requestCallback` to conform to its role as a 'response' listener; notably, ensure it is called when the first argument is interpeted as the `http.IncomingMessage`, and _not_ called in the event of an error (as expected by `Optimizely#_sendImpressionEvent`/`Optimizely#track`). Tested that this version (as 2.1.2-0) _does_ emit the messages expected in the demo app. Fixes #122 Fixes #124 # Conflicts: # packages/optimizely-sdk/lib/plugins/event_dispatcher/index.node.js # packages/optimizely-sdk/lib/plugins/event_dispatcher/index.node.tests.js
* Fix(nodejs/event_dispatcher): update error/resp handlers (#123) - (nodejs) Prevent crash when `http`/`https` emits an error by adding an 'error' listener - (nodejs) Fix `requestCallback` to conform to its role as a 'response' listener; notably, ensure it is called when the first argument is interpeted as the `http.IncomingMessage`, and _not_ called in the event of an error (as expected by `Optimizely#_sendImpressionEvent`/`Optimizely#track`). Tested that this version (as 2.1.2-0) _does_ emit the messages expected in the demo app. Fixes #122 Fixes #124
* Fix(nodejs/event_dispatcher): update error/resp handlers (#123) - (nodejs) Prevent crash when `http`/`https` emits an error by adding an 'error' listener - (nodejs) Fix `requestCallback` to conform to its role as a 'response' listener; notably, ensure it is called when the first argument is interpeted as the `http.IncomingMessage`, and _not_ called in the event of an error (as expected by `Optimizely#_sendImpressionEvent`/`Optimizely#track`). Tested that this version (as 2.1.2-0) _does_ emit the messages expected in the demo app. Fixes #122 Fixes #124
Since #98 removed the request library in favour of the stock Node HTTP implementation, the Optimizely SDK no longer supports HTTP(S) Proxies, as Node does not proxy by default (as documented here nodejs/node#15620).
We host our feature branches on a PAAS that requires outbound HTTP connections be proxied: As a result this bug currently causes our application to crash with the error below when calling
optimizely.activateThis error can't be caught, because it occurs asynchronously to the main control flow of the application, and thus causes the entire application server to crash.
The text was updated successfully, but these errors were encountered: