New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't switch off Debug mode #719

Closed
vitaly-t opened this Issue Aug 2, 2015 · 5 comments

Comments

Projects
None yet
3 participants
@vitaly-t
Contributor

vitaly-t commented Aug 2, 2015

Using the latest version, can no longer switch off the long-stack tracing, or the entire debug mode for that matter:

  • setting BLUEBIRD_DEBUG=0 - no effect;
  • setting NODE_ENV=production - no effect.

Had to go manually comment some code out to make the long-stack tracing go away:

var debugging = false/* || (util.isNode &&
                    (!!process.env["BLUEBIRD_DEBUG"] ||
                     process.env["NODE_ENV"] === "development"))*/;

what's going on???!!!

@spion

This comment has been minimized.

Show comment
Hide comment
@spion

spion Aug 3, 2015

Collaborator

Works fine here. My guess is that something in your environment is turning on BLUEBIRD_DEBUG or is setting the NODE_ENV to development. I'd suggest to grep for process.env

If you want to disable BLUEBIRD_DEBUG you either have to unset it or set it to an empty string e.g. BLUEBIRD_DEBUG=''. That wont help if something is setting NODE_ENV though.

Collaborator

spion commented Aug 3, 2015

Works fine here. My guess is that something in your environment is turning on BLUEBIRD_DEBUG or is setting the NODE_ENV to development. I'd suggest to grep for process.env

If you want to disable BLUEBIRD_DEBUG you either have to unset it or set it to an empty string e.g. BLUEBIRD_DEBUG=''. That wont help if something is setting NODE_ENV though.

@spion spion closed this Aug 3, 2015

@vitaly-t

This comment has been minimized.

Show comment
Hide comment
@vitaly-t

vitaly-t Aug 3, 2015

Contributor

I did debugging for this thing, and I found that if I set BLUEBIRD_DEBUG=0, then when your code calls !!process.env["BLUEBIRD_DEBUG"], that expression is true, because !! applied to a string that contains "0" is true.

That's a clear bug. Please re-open the issue.

Contributor

vitaly-t commented Aug 3, 2015

I did debugging for this thing, and I found that if I set BLUEBIRD_DEBUG=0, then when your code calls !!process.env["BLUEBIRD_DEBUG"], that expression is true, because !! applied to a string that contains "0" is true.

That's a clear bug. Please re-open the issue.

@spion

This comment has been minimized.

Show comment
Hide comment
@spion

spion Aug 3, 2015

Collaborator

Reopening because accepting BLUEBIRD_DEBUG=1 to enable but not accepting BLUEBIRD_DEBUG=0 to disable long stack traces is bad UX.

There are a few things we might want to consider:

If the value is "0", should that override NODE_ENV?

Resulting logic would be process.env.hasOwnProperty("BLUEBIRD_DEBUG") ? isTruthy(process.env["BLUEBIRD_DEBUG"]) : process.env["NODE_ENV"] == "development"

If the value is anything other than "0" (e.g. "false" etc) should we handle those cases too?

isTruthy would handle this - if we decide to only accept "0" it would simply be !!arg && arg != "0"

Collaborator

spion commented Aug 3, 2015

Reopening because accepting BLUEBIRD_DEBUG=1 to enable but not accepting BLUEBIRD_DEBUG=0 to disable long stack traces is bad UX.

There are a few things we might want to consider:

If the value is "0", should that override NODE_ENV?

Resulting logic would be process.env.hasOwnProperty("BLUEBIRD_DEBUG") ? isTruthy(process.env["BLUEBIRD_DEBUG"]) : process.env["NODE_ENV"] == "development"

If the value is anything other than "0" (e.g. "false" etc) should we handle those cases too?

isTruthy would handle this - if we decide to only accept "0" it would simply be !!arg && arg != "0"

@spion spion reopened this Aug 3, 2015

@vitaly-t

This comment has been minimized.

Show comment
Hide comment
@vitaly-t

vitaly-t Aug 3, 2015

Contributor

There was a breaking change in one of the recent releases, because I've been using BLUEBIRD_DEBUG=0 for a while, as was suggested to me here a while ago, and it worked. It stopped recently, not sure when exactly, I just noticed by accident that my tests on Travis where I used BLUEBIRD_DEBUG=0 started showing huge slow-down, so I went investigating till found the culprit.

Contributor

vitaly-t commented Aug 3, 2015

There was a breaking change in one of the recent releases, because I've been using BLUEBIRD_DEBUG=0 for a while, as was suggested to me here a while ago, and it worked. It stopped recently, not sure when exactly, I just noticed by accident that my tests on Travis where I used BLUEBIRD_DEBUG=0 started showing huge slow-down, so I went investigating till found the culprit.

@spion

This comment has been minimized.

Show comment
Hide comment
@spion

spion Aug 3, 2015

Collaborator

@vitaly-t if thats the case, then which is the version that accepts BLUEBIRD_DEBUG=0 ? I checked and equivalent logic goes back at least 6 months.

As far as I know, BLUEBIRD_DEBUG=0 has never worked - what has worked was unset BLUEBIRD_DEBUG and BLUEBIRD_DEBUG=''

Collaborator

spion commented Aug 3, 2015

@vitaly-t if thats the case, then which is the version that accepts BLUEBIRD_DEBUG=0 ? I checked and equivalent logic goes back at least 6 months.

As far as I know, BLUEBIRD_DEBUG=0 has never worked - what has worked was unset BLUEBIRD_DEBUG and BLUEBIRD_DEBUG=''

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment