Skip to content

Enable error handling when streaming#647

Open
paulmelnikow wants to merge 1 commit intoaheckmann:masterfrom
paulmelnikow:stream_error_handling
Open

Enable error handling when streaming#647
paulmelnikow wants to merge 1 commit intoaheckmann:masterfrom
paulmelnikow:stream_error_handling

Conversation

@paulmelnikow
Copy link
Copy Markdown

@paulmelnikow paulmelnikow commented Mar 28, 2017

See discussion of the problem in #256 (and a bit more in #548).

Adding proc to the .stream() callback seems like the easiest way to allow the caller to handle this. Tested in a downstream package and it works, though it's not terribly convenient.

When no callback is provided, emit an error event on the throughStream.

Before and after this change, I have two failing tests, which appear to be unrelated.

Comment thread lib/command.js
* @param {String} name
* @param {Function} callback
* @return {Object} gm
* @return {null}
Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No change in behavior. This is a documentation fix.

Comment thread lib/command.js
else stdout.pipe(throughStream);
proc.on('error', function (err) {
throughStream.emit('error', err);
});
Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not strictly necessary, but seems useful. ^^

Comment thread lib/command.js
} else {
cb(err);
}
});
Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved this block for clarity. It is only effective when bufferOutput is true. See discussion in #256.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense. Just, to explain for the next reviewer:

  • there's code to prevent the callback to be called more than once
  • when !buffer case calls the callback immediately

So, when !buffer this error would be swallowed by the code that prevents the callback to be called more than once.

@paulmelnikow
Copy link
Copy Markdown
Author

Same errors are appearing in CI. Again, I don't think they are related to this change.

@paulmelnikow
Copy link
Copy Markdown
Author

@aheckmann Could you take a look, please? Would be great to get this fixed for badges/shields#914.

@pmoleri
Copy link
Copy Markdown

pmoleri commented Jan 21, 2019

Hi @aheckmann , this is an important PR, otherwise the use of .stream() is unreliable.
I guess the PR would have to get rebased, if that's done, would you merge it?
Thanks.

@jonlil
Copy link
Copy Markdown

jonlil commented Jun 29, 2023

Hello, I bumped into this in one of my projects today and I more or less solved it by bypassing .stream() like the following.
And if somebody else stumbles onto this here is one solution to at least notice the warnings

async function gmToBuffer (data) {
  return new Promise((resolve, reject) => {
    let chunks = [];
    data._preprocess((err) => {
      if (err) return reject(err);

      data._spawn(data.args(), false, (err, stdout, stderr) => {
        if (err) return reject(err);

        stdout.on('data', (chunk) => chunks.push(chunk));
        stdout.once('end', () => resolve(Buffer.concat(chunks)));
        stderr.on('data', (msg) => {
          const error_message = String(msg);
          if (error_message.includes('@ warning/')) {
            logger.error(error_message);
          } else {
            stdout.emit('error', new Error(error_message));
          }
        });
        stdout.once('error', (err) => reject(err));
      });
    });
  });
}

And to be specific I wanted to still get the warning and not just silence them.

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

Successfully merging this pull request may close these issues.

3 participants