Skip to content

debug.enable() NOT dynamic #871

Closed
Closed

Description

@KevinAst

I am new to debug logger and I thank you for your awesome utility.

In my experience, using debug.enable('myProj:myModule:myFn') does NOT dynamically impact the logging filters in the current process (in either the browser or node). It merely resets the DEBUG env var (or the browser's localStorage.debug). The process must then be re-started for it to take effect.

I am using the latest 4.3.3 release.

I must be doing something wrong, as the README docs clearly state that enable() dynamically resets the filter.

The ability to dynamically change the logging filters (without restarting the process) is a crucial feature for production code, especially in a node/server environment.

I have searched both the debug project issues -and- stackoverflow with no luck. I did find a number of enable() issues, but none that seemed to match my problem.

One thing I considered is I am creating my log instances in a "module scope", so my probes live a lifetime in the process. Is this an incorrect usage? Should I be creating log instances in a function scope, so they are re-created on each function invocation? I tried a quick test of this, and it seemed the results were the same (still no dynamic behavior).

From an application perspective, this feature would seem to be very rudimentary ... so as I stated, I must be doing something wrong.

Any help would be greatly appreciated.

Activity

  1. Qix- commented on Feb 25, 2022

    @Qix-
    Member

    It might be the case, honestly. Using debug.enable() is very highly discouraged and hasn't worked "correctly" since it was written. I know that's probably not the answer you want to hear.

    You should be using the DEBUG environment variable whenever possible. Setting individual debugger enabled properties should also work correctly. The top-level debug.enable() function is a mine field and has multiple documented issues.

    From an application perspective, this feature would seem to be very rudimentary ... so as I stated, I must be doing something wrong.

    One of those situations that seems simple until you go to implement it and try to make it performant and realize you're slowing everyone down when you try to simplify things.

  2. KevinAst commented on Feb 25, 2022

    @KevinAst
    Author

    Thanks for your quick response @qix.

    Please Note that since my original post had not been responded to, I re-worded it (removing some off-topic questions), and updated it with my latest results (I actually got it working)!

    • I may ask my off-topic questions on a new issue.

    • I would really like your thoughts on the Mine Field Future?.

    FYI: When I used the term "rudimentary" (above), I was not implying that it was easy to implement, rather that it's usage was easy (not understanding how I messed it up :-)

    Background

    Certainly in a development environment it is feasible to use the DEBUG env var. However I am working on a server-based administrative utility that provides the ability to dynamically alter the filters in a production deployment (without re-starting the server). In this context, the debug.enable() feature is crucial in diagnosing unexpected conditions in production.

    Thoughts?

    Regarding My Problem - NOW FIXED!

    For what it is worth, I just now resolved my problem and it is working very well :-)

    | debug.enable(filter) now works BOTH on my client (a Svelte web-app) and my server (a Node app).

    As I mentioned, I am working with a MonoRepo. I analyzed it to insure there were consistent top-level npm versions of the debug lib (across all the packages of my MonoRepo). In my case I found a "rouge" top-level npm debug lib installed on my server that was sorely out-of-date. I'm not exactly sure where it came from (I did not install it). I suspect it originated from one of my dev-dependencies that in-turn uses the debug lib.

    Bottom line is, once I explicitly installed the latest debug lib in all my MonoRepo packages, everything started working (both client and server). I can even enable logs of other packages (by using the "*" filter) ... for example socket.io.

    Mine Field Future?

    Regarding the debug.enable() "mine field", are there plans to shore shore this up (possibly in a major release)? As I mentioned, this is a crucial feature for projects that are retaining their logging probes in production.

    Thoughts?

    Thanks

    Thanks in advance, for your time and response.

  3. Qix- commented on Mar 4, 2022

    @Qix-
    Member

    are there plans to shore shore this up

    Yes, quite a few issues are open about it. Checked the pin roadmap issue #656 which mentions the various pieces of the .enable() puzzle.

    Unfortunately I'm all too familiar with the problems of .enable(), so there's not much else to be said here. It's a known problem, and there are plans to fix it. Just a matter of when. Not much I can do here but to direct you to the other issues, sorry about that.

  4. added
    questionThis issue asks a question or requests usage support
    on Mar 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    questionThis issue asks a question or requests usage support

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions