Handle connectivity issues while reading the body #1343
Conversation
|
It looks like there is a problem with Node v14, looking into it. |
| cleanListeners() | ||
| this._openRequests-- | ||
| request.once('error', () => {}) // we need to catch the request aborted error | ||
| request.abort() |
There was a problem hiding this comment.
If you use request.destroy() it might solve the v14 problem and it will also not emit an error event so you will no longer need the empty error handler.
There was a problem hiding this comment.
Thanks for the review! I'm looking into this, as request.abort has been deprecated in newer versions of node.
Very likely I'll address this in a separate pr while working on #1297.
|
Thanks to the awesome Node.js contributors I've discovered the |
delvedor
changed the title
|
The backport to To backport manually, run these commands in your terminal: # Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-7.x 7.x
# Navigate to the new working tree
cd .worktrees/backport-7.x
# Create a new branch
git switch --create backport-1343-to-7.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick ---mainline 1 edd4f78badb47b96120d60e36f0c0f16dd7584e6
# Push it to GitHub
git push --set-upstream origin backport-1343-to-7.x
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-7.xThen, create a pull request where the |
lib/Transport.js
Outdated
| @@ -237,9 +237,9 @@ class Transport { | |||
| if (isCompressed) { | |||
| payload = Buffer.concat(payload) | |||
| } | |||
| if (result.headers['content-length'] !== undefined && Number(result.headers['content-length']) !== payload.length) { | |||
| if (result.headers['content-length'] !== undefined && Number(result.headers['content-length']) !== Buffer.byteLength(payload)) { | |||
There was a problem hiding this comment.
That´s why everyone loves javascript 👯♀️
|
We have the same issue.. I noticed something strange... For all requests failing the _source: reply from ES to Kibana contains a 3 bytes UTF-8 Bom inside the JSON string.. not sure if this is even legal: |
|
hi, possible to back port this fix on 5.x ? |
Until now the client was not verifying the
content-lengthheader, this pr address this issue.For supporting this, the unzip process has been moved from the
Connectionclass to theTransportclass.A byproduct of this pr is the fix of #1088.
Closes: #1088
/cc: @msisti @tomsquest