v1.2.0 release candidate

[cbraynor]

Changes to the way error objects are handled by the reject() callback function and adding an option to suppress storing stack traces in the task's database location for security reasons

/cc @dreadjr

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request) and all commit authors, but as best as we can tell these commits were authored by someone else. If that's the case, please add them to this pull request and have them confirm that they're okay with these commits being contributed to Google. If we're mistaken and you did author these commits, just reply here to confirm.

[dreadjr]

this looks great.

[cbraynor]

@googlebot confirm

[m-tse]

What's the reason for this? Passing a plain string into reject() should work as well correct?

[dreadjr]

I am a fan of using Error because it allows you to attach other
properties, etc. You could put the number of errors, etc. Also could create
custom errors for these scenarios. But yes, a string works too.

On Tue, Jun 16, 2015 at 10:20 AM, Matthew Tse notifications@github.com
wrote:

In src/lib/queue_worker.js
#24 (comment):

@@ -113,7 +119,7 @@ QueueWorker.prototype._resetTask = function(taskRef, deferred) {
} else {
var errorMsg = 'reset task errored too many times, no longer retrying';
logger.debug(self._getLogEntry(errorMsg), error);

•    deferred.reject(errorMsg);
  

•    deferred.reject(new Error(errorMsg));
  

What's the reason for this? Passing a plain string into reject() should
work as well correct?

—
Reply to this email directly or view it on GitHub
https://github.com/firebase/firebase-queue/pull/24/files#r32546129.

[m-tse]

LGTM