Hi Folks! The last few weeks have been incredibly busy. In this edition I include a brief explanation of Logging - the process of creating log lines as a byproduct of an application. Read up!
I’ve included all last releases for modules, barred Platformatic… which we released multiple times per week, working hard to fix all bugs for old and upcoming features!
One of the biggest misconceptions about logging is that it is a safe operation. It's far from safe: it's an unbounded memory leak. Whenever you log a line, you allocate memory released when the line is written to its destination. What happens if your destination cannot keep up with the number of log lines your application produces? This is primarily theoretical, as most extreme logging scenarios would resolve themselves given enough time (and memory), but it's good to consider what happens in those cases. This situation usually comes as an EBUSY error code, meaning the disk is full. There are three options to handle this situation:
The first option is to slow down your application, typically by synchronously waiting for the EBUSY or EAGAIN to be resolved. This usually degrades the end-user experience and is also very tricky to debug.
Dropping log lines if the destination is busy is a radical option to preserve end-user experience at the cost of observing what is currently happening, degrading the operator experience.
Crashing for an out-of-memory error is destructive, losing all ready-to-be-delivered logs. However, it is very noisy and provides the best approach for the operator, who now knows they should handle this case.
In Pino, writing the logline can happen synchronously or asynchronously. In synchronous logging, the only possible option to deal with a slow hard disk is to wait for it to be available again. In asynchronous logging, pino will buffer the lines and retry at given intervals.
We chose to log asynchronously by default, as it provides the best performance for your application. However, it will crash your application in case of a slow destination and a lack of available memory.
While this case is uncommon, a few companies at a massive scale had this issue. Mary Marchini had this issue and contributed the fix: implement the
retryEAGAIN() option is sonic-boom to drop the bytes that the destination could not absorb, as slowing things down was not option.
I've published the videos of me adding ARRAY columns support to Platformatic DB. Who knew PostgreSQL supported arrays as a column type? This would have drastically changed most of my SQL exams at University! Watch Part 1 and Part 2.
Follow along with the progress at https://github.com/platformatic/platformatic/pull/1275.
ERR_REP_ALREADY_SENTthat a route may be missing
return reply; it also fixes a few TS bugs.
Set-Cookieheader multiple times for the same cookie anymore. v9.0.1 fixes the inevitable regression for a major release. v9.0.2 ships a few more bugfixes and performance improvements. v9.0.3 and v9.0.4 fix the CORS regression.