Winston: Logging to file fails when calling process.exit(0)

In node the console.* methods are writing async, the File transport is async. You are closing the process before node has even written data.

On Monday 25 March 2013 at 19:45, Yuri Zapuchlak wrote:

When you have winston configured to log to a file and you call process.exit(0) in your code, winston never ends up creating the log file and appending the log messages to the file.
In a perfect world, winston would happily handle this edge case and write to the file, but I'd also be fine with being able to call flush on a logger instance in order to manually force a flush to file.
There may be some way to manually 'flush' at the moment, but it's not documented nor have I had any luck with manually to closing/ending/destroying a logger instance or its inner streams so far in a way that actually results in the loges being written out to a file..
var winston = require('winston'); var logger = new (winston.Logger)({ transports: [ new (winston.transports.Console)(), new (winston.transports.File)({ filename: 'winston.log' }) ] }); logger.info('info logged'); logger.error('error logged'); process.exit(0); // the two logs get written out to console, but not to the winston.log file/

—
Reply to this email directly or view it on GitHub (https://github.com/flatiron/winston/issues/228).

Hmm. In that case, if one must kill a node process but needs to log information right before they kill it, is putting the process.exit() inside of a setTimeout() with a sufficiently large time duration the only thing one can do to ensure that winston actually writes messages to the log file?

Just for clarity, console.log and friends are synchronous.

@yzapuchlak I haven't actually tested, but that's what I do too.

@yzapuchlak setTimeout will _probably_ work without problems, but I think it would be wise to use the optional callback param instead.

setTimeout of 2000 or 5000 works in my simple test script, but not when I try to use it in my real code. So, I don't know how reliable that potential fix will be. I'll dig into that problem later if I have no luck on the optional callback front.

@dtex I just tried use the optional callback (as seen in the following example code), but it's still not resulting in the logs getting written to the file. The file actually gets created in this case but no logs get written to it.

var winston = require('winston');
var logger = new (winston.Logger)({
  transports: [
    new (winston.transports.Console)(),
    new (winston.transports.File)({ filename: 'winston.log' })
  ]
});

logger.info('winston - info logged');
logger.error('winston - error logged');

logger.info('winston - exiting now', { seriously: true }, function(err, level, msg, meta) {
  console.log('console - CALLING PROCESS EXIT');
  process.exit(0);
});

logger.warn('winston - I probably should only appear in console, not the log file?');

@yzaouchiak Curious, is that version 0.6.2?

└─┬ [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
└── [email protected]

Having same issue now, need to terminate process and make a note in the log file. Would be nice to have callback option, which we could use to exit process only after message was written. Or maybe it's already exist?

I'm having the same issue, with Winston 0.7.2.
I tested setTimeout and callback workaround without any success.

This is the same issue as #288 and also the log4js-node issue (https://github.com/nomiddlename/log4js-node/issues/148). I think the problem is that the event loop does not run once the process.exit callback has finished - so any pending async calls (like file writes) don't get a chance to run. I'd be very happy if someone can prove me wrong, and come up with a fix.

I am willing to dedicate time to fixing this if we can come up with a solution. The key issue seems to be that WritableStreams do not guarantee flushing on process.exit() or unhandled exception. Have any alternative solutions been investigated? It seems like we could cache the logs in memory until the WritableStream drains. Then if a process.exit or uncaught exception occurs, we can synchronously write any logs that have not been drained. This might produce duplicate logs, but would at least prevent logloss. Any thoughts?

Related to https://github.com/nomiddlename/log4js-node/issues/148

Related to #288.

Any updates here? Still failing for me with ~ 0.9.0

Yeah, I am still using the setTimeout() hack mentioned by @yzapuchlak previously :(

I don't really see this as a bug of winston anyways. When you process.exit in your code you have made the decision to completely kill everything that is still running on processing. If there are still HTTP requests running you don't assume that these will also be replied to, so why would assume that log messages do end up in your log? This is just how node works things are async for a reason. If if you used the callback or setTimeout approach there is nothing preventing your application to log another line right before your setTimeout is done or callback is called.

The only ways around this is to have synchronous logging but then you defeat the whole purpose of having an async system as a simple log statement when you're handling requests..

So what i'm suggesting is closing this issue with a wont fix. If you don't want to mis any log messages make sure you correctly clean up and shut down your application before calling process.exit.

edit Also all your setTimeout hacks are flawed and do not fix the issue as you have no idea how long it will take to have all data be written to the operating system and how fast your disks or ssds's are processing it. The only decent solution here is to listen to the stream's drain event and exit the process. But if you application is continuously logging this might not even be called for a long period ;p making this just another hack because you didn't properly shutdown your application before exiting.

The thing is there is currently no way to wait (callback/promise/whatever) for logs to be flushed. Also forcing sync logging would make it possible to add logs in process.on('exit')

If you want to have async logging during the life time of your application and sync logging during process.exit you should create a new winston instance with a custom file implementation that does sync writes. And if you want to know when things are flushed you should listen to the drain event of a stream.

I'll try that, thanks!

For what it's worth, you can get around the use of setTimeout but you need to grab the underlying _stream:

// log then exit(1)
logger.error("The thing to log", function(err) {
  var numFlushes = 0;
  var numFlushed = 0;
  Object.keys(logger.transports).forEach(function(k) {
    if (logger.transports[k]._stream) {
      numFlushes += 1;
      logger.transports[k]._stream.once("finish", function() {
        numFlushed += 1;
        if (numFlushes === numFlushed) {
          process.exit(1);
        }
      });
      logger.transports[k]._stream.end();
    }
  });
  if (numFlushes === 0) {
    process.exit(1);
  }
});

As mentioned above, use of the callback function alone is _not sufficient_ to get it to have flushed correctly to file. This feels like a bug to me.

Note that I'm actually listening for the finish event: https://nodejs.org/api/stream.html#stream_event_finish rather than using winston's flush or closed event because that too is insufficient to get it to log correctly :/

Try this one. It works pretty well in my case. Instead of calling process.exit directly we let the logger call process.exit after the log was flushed.

logger.js :

var winston = require('winston');

winston.loggers.add('my-logger', {
    console: {
        level: 'debug',
        colorize: true,
        timestamp: true,
        handleExceptions: true
    },
    file: {
        level: 'info',
        colorize: false,
        timestamp: true,
        filename: 'file.log',
        handleExceptions: true
    }
});

var logger = winston.loggers.get('my-logger');


/* ******* *
 * EXPORTS
 * ******* */

exports.exitAfterFlush = function(code) {
    logger.transports.file.on('flush', function() {
        process.exit(code);
    });
};

exports.info = function() {
    logger.info.apply(this, arguments);
};

exports.warn = function() {
    logger.info.apply(this, arguments);
};

exports.error = function() {
    logger.info.apply(this, arguments);
};

in your code:

var logger = require('./logger.js');
logger.exitAfterFlush(0);
logger.info('Done!');

Tested on NodeJS v4.1.2 and winston 1.1.0

I'm using something similar to @da-mkay.

function closeAllLoggersAndDisconnect() {
    "use strict";

    let openCount = 0;

    Object.keys(loggerInstance.transports).forEach((key) => {

        let transportInstance = loggerInstance.transports[key];

        if (typeof transportInstance.close === "function") {
            transportInstance.close();
            openCount++;
        }

        transportInstance.on("closed", () => {
            openCount--;
        });

        setInterval(() => {
            if (openCount === 0) {
                if (process.connected) {
                    process.disconnect();
                }
            }
        }, 100);
    });
}

in your code:

winston.error("Error Occured", err, () => {
    closeAllLoggersAndDisconnect();
});

Ideally it would be nice if I could just call the close method on the loggerInstance, but since that emits the closed event as soon as it finishes calling the close method on the underlying transports, instead of after they actually close, that won't work. It seems that it is a bug that the logger can be closed without the underlying transports being fully closed.

Using @Kegsay steps and logs are written to file.

Also using @Kegsay 's steps with success... wrapped in my own function.

Still have this issue on version 2.2.0.

Is this still not implemented? More than 3 years old. I don't wanna use process exit.

I understand that this is not an issue but there should definitely be a function to finish all writes to files and close any open stuff so that the process can exit on its own without calling it explicitly. So hard to use such things in production systems.

npm install winston-log-and-exit

Echoing that this really does need a solution on winston's side. Whether that's providing a synchronous file transport or providing a shutdown hook to close down Winston 'safely' I don't really care, either would be a satisfactory solution to me. But having nothing just makes it impossible to write logs and then quit and be assured that they will actually be written.

The thing with synchronous transports, is that the execution of your code will be blocked until the IO completes, which limits performance. There's no way to convert an async write to a blocking write, which means once you async-write to the logs, you have to wait until NodeJS gets around to it, and in the mean time other JS code may be executed.

On the other hand, promises can be canceled synchronously, timeouts can be cleared synchronously, file and database connections can be closed synchronously, so a better (more performant) solution might be to keep track of the things that need to be canceled/cleared/closed and close them in the exception handler that calls winston.log_and_exit(), or the optional callback to winston.log_and_exit().

Sure it would be nice if Winston kept track of all the things that you would need to close in the event of an error, but such a task manager would probably be a useful thing in it's own right, and probably deserves a separate framework (see Curley's law).

I don't see how performance has any impact here. The process is about to be killed, winston only needs to do bookkeeping on the final log lines during which time it can happily block IMO.

Given how old this issue is, and the fact that there is a workaround for it, I'm not exactly holding out for anyone addressing this in winston anytime soon.

It sounds like you and I are talking (writing) across purposes. It sounds like you are interested in synchronously writing final messages to file, whereas my concern was ensuring that the logs which were written asynchronously just before the error get written to file.

Writing the messages to file that occurred just before the error synchronously would require that all messages are written synchronously, and that is the performance issue.

Others have been concerned about stopping other JS code from running after an error but before the last logs have been written to file.

An option that might satisfy everyone's needs is to write a custom transport which writes asynchronously, and keeps a buffer of messages not yet confirmed as written (flushed) to file, which could be written to file synchronously on error (at the risk of duplicating messages, in the case that NodeJS already finished writing to file, but the flushed event hasn't been processed yet...).

Is it actually difficult to provide a shutdown hook to call that would wait till everything was flushed before returning and/or calling a callback? This would solve pretty much every use case.

But let me also tell you about my use case, the reason I don't care about synchronous logs. Tests. I don't care if my tests take a second or two longer to run. I do care if the logs are non deterministic because they may or may not be written out depending on exactly how quickly node decides to shut down. That is bad. I agree whole heartedly that asynchronous should be the default. I disagree that it should be the only option, especially in light of issues like this inside node itself.

@mscharley this is how log4js does it - there's a log4js.shutdown function which you can provide a callback. It will wait to make sure all the appenders (winston calls them transports, I think) have finished writing before it calls the callback. It seems to work fine for my users. It does require support from the appenders, in that they need to be written so that they can respond to shutdown calls.

I'm not trying to promote log4js or say that it is any better than winston, by the way - just pointing out that this approach can work. It may not be the best approach.

This is about what winston.log_and_exit() does. Note that log4js.shutdown() depends on writable.end(complete) in the case of appends based on writable streams, (appenders.filter(a => a.shutdown).forEach(a => a.shutdown(complete));) which is still an asynchronous shutdown.

I think with regard to @mscharley's comment, the advantage is that there is an fileSync appender, which does not require the use of shutdown() to have the complete logs written to file when the Node process quits...

Yes, having a fileSync transport would be useful in some situations, even if it would be a net performance decrease.

@jdthorpe I think your idea about having a library that handles closing things cleanly before shutting down is a good one but it still doesn't shift the responsibility away from winston to provide a method of waiting for it to flush everything to disk (ie, provide a mechanism to close itself) which could then be combined with such a library to aggregate up the close methods for various libraries.

Can this ticket at least change the docs so it doesn't look like it's currently supported I just spent 30 minutes debugging this issue which purports to be supported by when you search for seriously in the repo it's only supported in the README. This to be just seems like either an unsupported feature or a bug and the workarounds aren't really too palatable.

When will this be fixed? This has existed for 3 years now and is pretty important.

At least let us put a callback into the logger that actually works.

I would say maybe wrote a generic shutdown() function for everyone as a new feature, and this feature is pretty critical.

Yes this is a very, very important issue imo

+1 for this

Frankly, I think adding shutdown(callback) seems appropriate but with the caveat that transports need to actively support it. Individual transports are the "Information Experts" about their underlying output mechanism; they have the most information on how it should cleanly shutdown.

Anything the winston core does -- and most definitely anything we do in user land -- requires implementation details of the transports to leak.

So winston shouldn't need to do the work... but it really needs to provide a way for the work to get done. Then we can all go work with the Transport authors to do the heavy lifting.

Some psuedo-code to illustrate the point below.

```js
shutdown(callback) {
var transportCount = transports.length
var finished = 0;
// for each transport
if (transport.shutdown) {
transport.shutdown(function() {
// increase finished count.
// if all finished, call original callback.
});
} else {
// Transport does not (yet) support it.
// increment finished counter
}
}

https://github.com/ortexx/winston-callback

Would love to see this fixed in v3.x.

Here is my solution (assumes an environment that supports async/await)

const logTransport = new winston.transports.File({filename: '/log/app.log'})

global.log = winston.createLogger({transports: [logTransport]})

// helper to exit with a given return code, but only after the logger is finished
// this will return a Promise that will never resolve, thus halting execution
log.exit = (exit = 5) => {
  return new Promise(() => {
    logTransport.on('finished', () => process.exit(exit))
  })
}

</details>
<br>
Then, call with `await` like:

```js
try {
  something()
} catch(e) {   
  //do something with the error
  await log.exit(5) // <--- nothing will happen past this line as the promise will never resolve!
  // <--- process will have exited before it reaches here
  trySomethingElse() // <--- this will never be called, and control wont return to the calling code
}

Not to be a broken record, but winston-log-and-exit also solves this issue

Only for very, very specific use cases. I couldn't use winston-log-and-exit in say AWS Lambda where the process doesn't exit, but it does freeze between executions so logs still get lost. It also assumes I know which messages are my final ones which may not always be the case in a successful execution path.

@mscharley would the above await solution work for your use case? Perhaps instead of log.exit() a better api would await log.finish() which would wait until all transports have finished writing and then let you do whatever (call process.exit, call the lamda done callback, etc)

That is basically exactly what we've been pushing for in this issue, except inside Winston. Why would this be a plugin? Seems like something that should come up more often. I don't feel like what we're doing is anything special yet we've hit this wall on every project - which is why we moved away from Winston eventually. Loosing logs, especially at end of process - where errors are most likely to occur - seems hazardous at the least.

log4js-node has implemented a shutdown method with flushes all transports and takes a callback such as process.exit(). Could something like this be added to winston?

log4js-node it is then

any updates? Problem is very actual.

For any logging system, the calculus is:

• If you absolutely must have your logs and are willing to pay the cost of slower response times, use a synchronous logger
• If you are calling process.exit() yourself, wait until the buffered messages are cleared. For winston, the winston-log-and-exit package does this for you.
• If some other code is calling process.exit() and your platform has an on-exit hook, use that hook and wait until the buffered messages are cleared. winston-log-and-exit can help with that too.
• If you're using a platform like AWS Lambda which doesn't have an on-exit hook, then you're trading the benefits of the platform for the risk of loosing data.

Incidentally, @begin-again this the log_and_exit() method is essentially the same as log-4js's shutdown() method with the additional guarantee that the log message provided will be logged.

@jdthorpe But winston-log-and-exit wont easily work on winston 3

@VRuzhentsov Oh, well that is a problem. They should really do something about it.

@jdthorpe Fixed it with

const transport = new Transport();
const logger = createLogger({
  transports: [
    transport 
  ]
})

logger.finish = (exitCode) => {
  transport.on('finish', () => process.exit(exitCode));
  transport.close();
};

const shutDown = (exitCode) => {
  logger.info('Shutting down');
  logger.finish(exitCode);
};

shutDown(1);

The following works for me:

logger.info('winston - info logged');
logger.error('winston - error logged');
process.nextTick(() => {
    process.exit(0)
})

@redhat-raptor. That will work most of the time, but it's not guaranteed to work all of the time. It just happens that your buffers were cleared by the time nextTick() was called, but depending on the connections that your loggers rely on, this could easily result in lost messages...

This code worked for me:

            logger.error(`No value specified for ${value} variable! Node will exit now...`);
            logger._flush(() => {
                process.exit(1);
            })

Isn't this natively supported in v3?

https://github.com/winstonjs/winston/blob/master/README.md#awaiting-logs-to-be-written-in-winston

@danielweck Nope, it is broken: #1629 #1504!

6 years, that is right, 6 years for a bug that is marked _important_. It is borderline impressive.

I use a waitForWinston() Promise:

const winston = require('winston');

const fileTransport = new winston.transports.File({ name: 'file', filename: FILE_PATH });
const consoleTransport = new winston.transports.Console({ name: 'console', stderrLevels: ['error'] });
const transports = [
    fileTransport,
    consoleTransport
];
winston.configure({
    level: 'verbose',
    transports,
    format: winston.format.cli()
});
winston.log('info', 'TEST MSG');
try {
    await waitForWinston();
} catch (err) {
    console.log(err);
}
process.exit(0);

const waitForWinston = async () => {
    return new Promise(async (resolve, _reject) => {
        for (const transport of transports) {
            try {
                await closeWinstonTransportAndWaitForFinish(transport);
            } catch (err) {
                console.log(err);
            }
        }
        resolve();
    });
};

const closeWinstonTransportAndWaitForFinish = async (transport) => {
    if (!transport.close) {
        // e.g. transport.name === 'console'
        return Promise.resolve();
    }
    // e.g. transport.name === 'file'

    return new Promise(async (resolve, _reject) => {
        transport._doneFinish = false;
        function done() {
            if (transport._doneFinish) {
                return; // avoid resolving twice, for example timeout after successful 'finish' event
            }
            transport._doneFinish = true;
            resolve();
        }
        setTimeout(() => { // TODO: use a cancellable setInterval instead
            done();
        }, 5000); // just in case the 'finish' event never occurs
        const finished = () => {
            done();
        };

/* Update: `stream.end()` does not flush pending writes, so this solution is inadequate.  For some reason, in recent tests `transport.close();` + `transport.once('finish', ...);` works just fine ... not sure why this works now though! (it used to fail!) */

/*
        if (transport._stream) {
            transport._stream.once('finish', finished);
            transport._stream.end();
        }
*/
            transport.once('finish', finished);
            transport.close();
    });  
};

Update: stream.end() does not flush pending writes, so this solution is inadequate. For some reason, in recent tests transport.close(); + transport.once('finish', ...); works just fine ... not sure why this works now though! (it used to fail!)

In my working solution above, the key is to use:
transport._stream.once('finish', finished); transport._stream.end();
instead of:
transport.once('finish', finished); transport.close();
(the added timeout strategy is specific to my use-case, and is probably optional/redundant in the general case)

Easier way:

logger.error(`No value specified for ${missing_vars.join(',')} variable! Node will exit now...`, () => {
            process.exit(1);
        });

@danielweck Were you ever able to find a solution to this? We recently upgraded to Winston 3.x but may have to go back to 2.x or find a different logger without a solution here.

@matttowerssonos , IIRC, these problems are all related to Winston@2. Given the length of this thread, and the fact that you're not inquiring about the original posters comment, why not start a new thread with your problem?

BTW, I'm not seeing any issues with lost logs on Winston@3, so you might want to include your configuration in your new issue.

@cjbarth This does not work:

  process.on(type as any, (err: ErrorExtended) => {
    const processLogger: Logger = loggers.get('processLogger');

    processLogger.error(errorFormatter(err, type));

    processLogger.on('finish', function () {
      processLogger.end();
      console.log('never reaches here');
      process.exit(1);
    });
  });

processExit('uncaughtException');
// log and exit for unhandledRejection events.
processExit('unhandledRejection');

@stephanoparaskeva If I'm not mistaken, the finish event will never be fired on processLogger because you never call processLogger.end(). If you call that, then, when Winston is done logging, the finish event should fire.

I would also use process.disconnect() instead of process.exit(), which allows the queue to drain. It will exit automatically when the queue is drained.

@stephanoparaskeva If I'm not mistaken, the finish event will never be fired on processLogger because you never call processLogger.end(). If you call that, then, when Winston is done logging, the finish event should fire.

I would also use process.disconnect() instead of process.exit(), which allows the queue to drain. It will exit automatically when the queue is drained.

Gotcha, so something like this?

process.on(type as any, (err: ErrorExtended) => {
  const processLogger: Logger = loggers.get('processLogger');

  processLogger.error(errorFormatter(err, type));
  processLogger.end()

  processLogger.on('finish', function () {
    process.disconnect();
  });
});

// log and exit for uncaughtException events.
processExit('uncaughtException');
// log and exit for unhandledRejection events.
processExit('unhandledRejection');

@stephanoparaskeva That looks better.

I would typically bind the event handler before calling processLogger.end(), but it shouldn't matter because the finish event should fire only after the event loop turns, by which time the handler will be bound. I just think writing the code where the event handler is bound first makes it clearer.

@cjbarth
Oh, how do you bind the event handler to something?
Would that be:

processLogger.on('finish', () => {
    this.process.disconnect();
  });

@stephanoparaskeva Yes. That is the correct syntax for binding the function

{
  this.process.disconnect();
}

To the finish event emitted by the object processLogger.

It works for me: https://stackoverflow.com/a/59260151

If you don't call process.exit but do a proper shutdown instead, by closing all connections and waiting for the event loop to drain, then there is no problem at all.

See this: https://stackoverflow.com/a/37592669 to get a better understanding as to what @deedf is referring to. Following this advice, alleviated this problem for me as well.

The fact that the finish event still doesn't emit after years is just embarrassing at this point. This is going to be a pain to have to switch loggers and rewrite all my custom transports for them.

I don't get how this hasn't been solved yet by winston. I have a problem that only the very first logger in my code gets logged to Logstash (using also winston-elasticsearch). If I use logger.end() then everything gets logged, but the program exits too early. tried using all of the above solutions, and none really worked.
I'm really helpless

I don't get how this hasn't been solved yet by winston. I have a problem that only the very first logger in my code gets logged to Logstash (using also winston-elasticsearch). If I use logger.end() then everything gets logged, but the program exits too early. tried using all of the above solutions, and none really worked.
I'm really helpless

Did you try this ?

I don't get how people don't get that this "problem" hasn't been "solved" cause there isn't any. Just write proper code by not calling exit() and you'll be fine.

I don't get how people don't get that this "problem" hasn't been "solved" cause there isn't any. Just write proper code by not calling exit() and you'll be fine.

So our solution to this problem is to not call process.exit()?

I don't get how people don't get that this "problem" hasn't been "solved" cause there isn't any. Just write proper code by not calling exit() and you'll be fine.

So our solution to this problem is to not call process.exit()?

Yes, it's always a bad idea in nodejs, see https://stackoverflow.com/a/37592669

I don't get how people don't get that this "problem" hasn't been "solved" cause there isn't any. Just write proper code by not calling exit() and you'll be fine.

So our solution to this problem is to not call process.exit()?

Yes, it's always a bad idea in nodejs, see https://stackoverflow.com/a/37592669

Well the reason that I personally am using process.exit is because I am listening to uncaughtException and unhandledRejection to log to all my transports, then quit the application. Is there a better way to accomplish this issue?

I don't get how people don't get that this "problem" hasn't been "solved" cause there isn't any. Just write proper code by not calling exit() and you'll be fine.

Where did you see I said I used exit()?

I don't get how people don't get that this "problem" hasn't been "solved" cause there isn't any. Just write proper code by not calling exit() and you'll be fine.

Where did you see I said I used exit()?

Sorry for assuming your reading and understanding ability is sufficient to understand what this bug is about. Check the title again.

I don't get how people don't get that this "problem" hasn't been "solved" cause there isn't any. Just write proper code by not calling exit() and you'll be fine.

Where did you see I said I used exit()?

Sorry for assuming your reading and understanding ability is sufficient to understand what this bug is about. Check the title again.

You must be so busy if you come to an issue that's been open for 8 years and offer no proper help at all.

I don't get how people don't get that this "problem" hasn't been "solved" cause there isn't any. Just write proper code by not calling exit() and you'll be fine.

So our solution to this problem is to not call process.exit()?

Yes, it's always a bad idea in nodejs, see https://stackoverflow.com/a/37592669

Well the reason that I personally am using process.exit is because I am listening to uncaughtException and unhandledRejection to log to all my transports, then quit the application. Is there a better way to accomplish this issue?

I haven't used winston in a while, but won't it log thos anyway ? if not, won't rethrowing the error after logging it work ?

I don't get how people don't get that this "problem" hasn't been "solved" cause there isn't any. Just write proper code by not calling exit() and you'll be fine.

Where did you see I said I used exit()?

Sorry for assuming your reading and understanding ability is sufficient to understand what this bug is about. Check the title again.

You must be so busy if you come to an issue that's been open for 8 years and offer no proper help at all.

At least I can solve my own issues without whining like an entitled brat.