Poor handling of "sudo ddev hostname" - panic when sudo fails

What happened (or feature request):
Over in https://github.com/drud/quicksprint/issues/41 @jeolpittet reported what appears to be a perfectly obvious problem with sudo ddev hostname - We do a util.CheckErr() after it, which causes a panic and stacktrace, but the reality is that it can easily fail for various reasons (inadequate permissions, wrong password, etc).
https://github.com/drud/ddev/blob/73517397dcc6707411a7c961d9fe8be146731ed2/pkg/ddevapp/ddevapp.go#L936-L937
What you expected to happen:
How to reproduce this:
Version: Please include the output of ddev version, docker version and the project's .ddev/config.yaml.
Anything else do we need to know:
Related source links or issues:
Please use a complexity rating of 1-5 (5 is high) for a feature request. (High complexity implies more PR planning)

Would one of these things help? https://blog.kowalczyk.info/article/wOYk/advanced-command-execution-in-go-with-osexec.html
(I don't know any go)

No this is just a simple coding error :) Somebody (probably me) never thought about the fact that the sudo attempt could fail for various reasons.


[flow] add compatibility with node require()

Fixes #264. I forgot to take into account that not everyone who uses Flow uses ES Modules, so using a CommonJS export will you to use both:
const chalk = require('chalk');

as well as
import chalk from 'chalk';

It is fine to leave the export on the types however. Regardless if you're using CJS or ESM, you will be able to use import type syntax such as:
import type { Level } from 'chalk';

This will work even if you're using require because that flow import syntax is just stripped away with Babel just like the rest of the types.
I didn't add an additional test file which uses the require syntax, but I tested it locally and it worked. If you want me to add a _flow-node.js test file or something let me know and I can add that as well.

Ohh damn, I just made #266 to fix this too but didn't see your PR in time 😝

@pranaygp Since you're a first-time contributor here and the fact that your version actually makes more sense – (I'm not actually sure why I switched to a declaration syntax when using the CJS version, although both are fine), I'm going to close this and we can favor your PR instead.
If Sindre asks for another test file, you can just create a file in test called _flow-node.js or something and just copy all of _flow.js into it and just change the import syntax to require.


Update the Setting Up guide to point to new Node.js versions

Coverage remained the same at 96.465% when pulling ba3b1451b54d182ed4f32a87c97a5dc20969e717 on setting-up into 7cbb47bf55ce39af35108895d040903a5d9a07c0 on master.


NEAR Explorer Russian translation

This PR resolves https://github.com/near/bounties/issues/63

Hello, @nebezgreshniy!
I've made some changes to your translation, please check the PR.

@nebezgreshniy @dec0dOS Hey guys! Thanks for your contribution, you done well! I'll make a review soon

@shelegdmitriy @frol @telezhnaya
Hi, there!
Thanks for your review. I've fixed point remarks which took place due to the fact that I'm novel to the NEAR.

For review convenience, I have deployed the version of Explorer UI with this PR included for preview: https://near-explorer-frontend-with-indexer-temp.onrender.com/ (I had to push a new branch on the upstream repo to be able to deploy it, so we will need to push updates to feat/russian-translation-pr-738 branch to get new commits deployed)

Sorry if I duplicate comments

We need to translate datetimes https://near-explorer-frontend-with-indexer-temp.onrender.com/blocks/HLDZTafuWwz8Ddjdhh9TJK4Gm3xxz6DvHh8L5acAaWSd
https://near-explorer-frontend-with-indexer-temp.onrender.com/stats
"Batch Receipt" on first page

It seems that the Vietnamese version also has not translated the datetimes

@dec0dOS @nebezgreshniy Hey guys! We have a separate channel for discussing all the things. Please join https://t.me/near_explorer_ru_ch for discussing 😀

@think-in-universe Hey! I want to ask you whether there was some specific reason we did not use the official moment.js locales: https://github.com/moment/moment/tree/develop/locale. I would love to switch using those instead of duplicating that effort for every translation on Explorer


fix(newsletter): expose newsletter env vars to the client

What: expose newsletter env vars to the client
We forgot to add these variables to the env.sample file and we didn't add them to the netlify either.
Why: Fixes https://app.asana.com/0/1159164196409156/1198195877849653
How:

:tada: This PR is included in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


feat: Add a new published job stage

We added a new stage for Job in CVAT called published, which allows users to make one Job accessible to all members of their organization.

Motivation and context

First, thank you for the amazing project that has significantly helped us with our annotation program.
In our work, we encountered a problem: we want to provide annotation examples for new annotators to help them understand the annotation standards easily. However, with the current CVAT design, the only way to do this is by duplicating several Tasks and assigning each one to an annotator. While this method achieves our goal, it is not that convenient, and there is a risk that the annotators might accidentally change the pre-annotated examples.
Our ideal solution is that each annotator can share a single Job where they can only add comments by opening an Issue.
To achieve this, we added a new stage for Job, called published. If we change a Job to the published stage, any annotator with the link to this Job can view it and add comments.
How has this been tested?

Yes, we followed the Development environment guidelines and tested it on Ubuntu 22.04. The results were as we expected.
However, due to our limited knowledge of this project, we made the changes as minor as possible. We may also need your help to make this PR more useful in the future.
Checklist

[x] I submit my changes into the develop branch
[ ] I have created a changelog fragment
[x] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
- [ ] I have linked related issues (see GitHub docs)
- [ ] I have increased versions of npm packages if it is necessary
(cvat-canvas,
cvat-core,
cvat-data and
cvat-ui)

License

[x] I submit my code changes under the same MIT License that covers the project.
Feel free to contact the maintainers if that's a concern.

Summary by CodeRabbit

New Features

Introduced a new job stage, Published, to the application.
Added the ability to publish jobs, making them accessible to all organization members.
Updated filter options and configurations to include the new Published stage.
Enhanced the task progress bar to reflect the new Published stage.

Bug Fixes

Adjusted access control logic to handle the new Published job stage.

Documentation

Updated user manuals to include information about the new Published job stage and its impact on the annotation interface and task progress bar.

Show the published jobs count in the Tasks page.

Hi @bsekachev, could you please take a moment to review this PR and let me know if it can be merged? Thank you!

how can i use your improved version, i also want to create a task multi-users can work in the same job and the database can store different annotations from different users

how can i use your improved version, i also want to create a task multi-users can work in the same job and the database can store different annotations from different users

I think the easiest way is to create a PR and merge this branch to your forked one, it seems that the CVAT team don't have a plan to merge this PR for now.
And for your case, I think you may need to make some changes in cvat/apps/engine/rules/*.rego to allow editing of annotations.


No parsing syntax error for variables in constant values

Description
The following should produce a syntax error, as variables cannot be used in constant value positions:
query($id1: ID, $id2: ID = $id1) {
  __typename
}

Apollo Compiler parses the above. By comparison, the graphql-js reference implementation produces the following parse error:
Syntax Error: Unexpected variable "$id1" in constant value.

Steps to reproduce
Try parsing the above query.
Expected result
Expected syntax error.
Actual result
Apollo compiler successfully parses

ah yep, that's a bug! thanks for reporting. I'll look into it next week.
this is a irl use case of issue reported in #538


Added panic message extraction.

This fixed panic messages being logged as:
Panic in (...): Any { .. } (the Any { .. } is literal, it's not a formatted string)
Now they're logged as:
Panic in (...): <the text of the panic if it's a string>
This code is based on https://github.com/guswynn/panic-message , which is based on https://github.com/rust-lang/rust/blob/4b9f4b221b92193c7e95b1beb502c6eb32c3b613/library/std/src/panicking.rs#L194-L200
It was verified to work locally with string based panics, custom formats won't work as well, but... dunno what to do about that.

Thanks for the PR. Seems like this got approved already so let's merge :D


⚠ Bofrost.at has degraded performance

In eb40577, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1522 ms

Resolved: Bofrost.at performance has improved in 8544e5c after 13 minutes.


FluentToastProvider  ShowCloseButton not implemented

Hi,
I needed to hide the FluentToast button close and I found this.
https://github.com/microsoft/fluentui-blazor/blob/41f8671c55d3ab38216ab57cd8dd9a8080c85044/src/Core/Components/Toast/FluentToastProvider.razor.cs#L43
But it is not used anywhere, why?

It seems it has been there from the beginning but it is indeed not used anywhere. I looked at the (internal) Toast design document again and it also should not be there.
From that doc:
Toast overview
Toasts, referred to as “notifications” in the UI, keep customers informed by briefly:

Confirming an action they took.
Informing the customer about a timely event.
Communicating the status of a process someone initiated.

The information in a toast is useful and relevant but never critical.
Based on that info and other guidance in the docs we implemented this as follows:
A Toast always needs to have the following call-to-action (dependent on the type of toast:

Confirmation Toast: Link; optional. If you do not supply an action to the ToastService call it defaults to dismiss
Communication Toast: required; Must be dismiss or timestap
Progress Toast: required; Must be dismiss or link

I'll mark the parameter as obsolete so we can remove it later.


(TypeScript) TablePagination infers incorrect keys for "classes"

[x] This is not a v0.x issue.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior 🤔

TablePagination should use TablePaginationClassKey for it's classes property in the shape of Partial<Record<TablePaginationClassKey, string>>
Current Behavior 😯

It infers TableCellClassKey in shape of Partial<Record<TableCellClassKey, string>> instead.
This is the TS error that gets thrown: https://hastebin.com/afejalagim.txt
Steps to Reproduce 🕹

Link: https://codesandbox.io/s/weathered-rgb-0s26k?fontsize=14&module=%2Fsrc%2FTablePagination.tsx
(optional) Bootstrap with Create-React-App for CSS modules. If doing this create a file named TablePagination.module.css and import it as seen in the codesandbox.

Set up a custom TablePagination component
Include a classes property
Include selectIcon and menuItem in the classes property

Context 🔦

I'm upgrading our Material-UI 3.x application to 4.0.0 and I'm facing this issue.
Your Environment 🌎

Tech
Version

Material-UI
v4.0.0

React
v16.8.6

React-Scripts
v3.0.1

Create-React-App
latest

Browser
Chrome, Firefox, Safari (all latest)

TypeScript
yes, v3.4.5

OS
MacOS

I ran into this issue this morning as well, see https://codesandbox.io/s/black-cloud-92i7u


Code Refactor of Application

Moved Application and ServletInitializer to /src/main/java for v0.3.0 Upgrade

Fixed some in #32


Logging out and in of a map adds more tiles to purchase

Hey there, noticed a bug while saving->quitting to menu-> loading save.
Game version is 1.0.18f1, BepInEx 5.4.22 and FiveTwentyNineTilesLite 1.1.1
Settings in game are "Allocate extra tiles to milestones" and "Select initial starting tiles"

As seen in first screenshot, fresh from booted up game, i am out of tiles to purchase. (21 purchased in total 9 from base, 4+5 from first milestones so im already off...)
Loading the game back 4 times and i now have 10 tiles to purchase :

it then goes 14-16 and seems to cap there. Quitting to desktop and then reloading seems to clear it back to 0.

Thanks for the report - confirmed.  Obviously the immediate workaround is to not do that, but I'll work on a proper fix.

Fixed in 1.2.1.  Please check to see that the issue has been resolved, and close this if it has.

Thanks for the quick fix, working as expected now.


Adding button dynamic resizing

@mmilkowski36 Give this a thorough test to see if everything works as intended.


⚠ Cioos National CKAN has degraded performance

In 59bc1ed, Cioos National CKAN (https://catalogue.cioos.ca/) experienced degraded performance:

HTTP code: 200
Response time: 26781 ms

Resolved: Cioos National CKAN performance has improved in 59026ac after 41 minutes.


gpr_cpu_test timeouts on master

https://grpc-testing.appspot.com/job/gRPC_master_linux/1647/consoleText
for dbg and opt

#9995 might be helpful


error structure with code

Hello, not sure if that's useful, but at least it forced me to have a look a bit everywhere in the code (-:. This replaces simple string errors by more structured ones, with a code, a human readable string and some JSON parameters. Also, I've removed calls to error to return IdeResponseFail.

It looks good, just have some simple travis failures

Oh, how come Travis builds with -Werror? I could of course build properly on my machine with stack build. Will fix later. thanks!

ok, I added a makefile and test locally with
make test

This builds with -Werror and runs the elisp tests too, so is representative
of the travis environment
On Wed, Nov 11, 2015 at 10:00 AM, JP Moresmau<EMAIL_ADDRESS>wrote:

Oh, how come Travis builds with -Werror? I could of course build properly
on my machine with stack build. Will fix later. thanks!
—
Reply to this email directly or view it on GitHub
https://github.com/haskell/haskell-ide-engine/pull/55#issuecomment-155697767
.

Warnings and tests addressed, make test is now successful.

Except you missed by a few minutes, need to merge now

Yep!! I'll do the merge on my side. Pray for me...

Should be pretty straightforward, I hope. I'm doing it too for my PR
On Wed, Nov 11, 2015 at 10:13 PM, JP Moresmau<EMAIL_ADDRESS>wrote:

Yep!! I'll do the merge on my side. Pray for me...
—
Reply to this email directly or view it on GitHub
https://github.com/haskell/haskell-ide-engine/pull/55#issuecomment-155897804
.


Block Weather works on GM's view but not player's view

Foundry: 0.8.7
FXMaster: 1.0.10
Weather Blocker: 0.6.1
Better Roofs: Not installed
Thanks for the awesome module. I was quickly testing this for the lower decks of a ship map. The blockWeather polygon is working 100% on my GM view, however if I log in as a player it does not work:
GM View:

Player View:

Edit: I noticed after updating the drawing while the player was connected, that it then works as expected. However, a refresh on the player's side (and also on the GM's side) and the weather is no longer blocked.
GM View:

Player View:

A quick double click on GM's side on the drawing and a "Update Drawing" will then have the weather blocked for both GM and player:
GM View:

Player View:

That is probably the same as the other reported issue, check if the problem persists with basic foundry weathers instead of fix master ones . If the issue doesn’t persist then you’ll have to wait until fxmaster updates for the issue to be fixed

Will have a look, thanks

It is possible that for the moment just installing better roofs will solve the issue

Tested as per your recommendation and it's definitely FX Master related. Will test separately with Better Roofs as well, but will mark this as closed as it's a duplicate if #2.


Update sudz.html

1.added an image of  Sudarshan Kamath
2.modified the form elements and reduced the size occupied by the form elements
3.made buttons as round-edged  and added a little space between them
Please review my code .

Great!


Launcher. Two vmoption files on linux

java.io.FileNotFoundException: failed to find default vmoptions file 	at com.intellij.remoterobot.launcher.IdeLauncher.readIdeDefaultVmOptions(IdeLauncher.kt:83) 	at com.intellij.remoterobot.launcher.IdeLauncher.launchIde(IdeLauncher.kt:33) 	at com.metalbear.mirrord.MirrordPluginTest$Companion.startIdea(MirrordPluginTest.kt:54)

I got similar issue with Mac and Win too. For me it is caused by *_client64.vmoptions files which present since around 2023.3 versions.


Assign default port to [ips_fixed] and [ips] if unspecified

Replaces previous behaviour where error was thrown.
Fixes issue #2861

Thank you for your submission. It will be reviewed soon and submitted for processing in CI.

Thank you for your submission. It will be reviewed soon and submitted for processing in CI.

Jenkins Build Summary
Built from this commit
Built at 20190516 - 00:47:04
Test Results

Build Type
Log
Result
Status

rpm
logfile
1177 cases, 0 failed, t: n/a
PASS :white_check_mark:

msvc.Debug
logfile
1177 cases, 0 failed, t: 579s
PASS :white_check_mark:

msvc.Debug, NINJA_BUILD=true
logfile
1177 cases, 0 failed, t: 611s
PASS :white_check_mark:

msvc.Debug -Dunity=OFF
logfile
1176 cases, 0 failed, t: 1096s
PASS :white_check_mark:

msvc.Release
logfile
1177 cases, 0 failed, t: 404s
PASS :white_check_mark:

gcc.Release -Dassert=ON, MANUAL_TESTS=true
logfile
915 cases, 0 failed, t: 5m6s
PASS :white_check_mark:

docs, TARGET=docs
logfile
1 cases, 0 failed, t: 0m1s
PASS :white_check_mark:

clang.Debug
logfile
1177 cases, 0 failed, t: 2m57s
PASS :white_check_mark:

gcc.Debug -Dcoverage=ON, TARGET=coverage_report, SKIP_TESTS=true
logfile
1177 cases, 0 failed, t: 16m55s
PASS :white_check_mark:

gcc.Debug
logfile
1177 cases, 0 failed, t: 3m5s
PASS :white_check_mark:

clang.Debug -Dunity=OFF
logfile
1176 cases, 0 failed, t: 7m1s
PASS :white_check_mark:

clang.Release -Dassert=ON
logfile
1177 cases, 0 failed, t: 4m53s
PASS :white_check_mark:

gcc.Debug -Dunity=OFF
logfile
1176 cases, 0 failed, t: 9m58s
PASS :white_check_mark:

gcc.Release -Dassert=ON
logfile
1177 cases, 0 failed, t: 5m8s
PASS :white_check_mark:

gcc.Debug -Dstatic=OFF
logfile
1177 cases, 0 failed, t: 3m2s
PASS :white_check_mark:

gcc.Debug -Dstatic=OFF -DBUILD_SHARED_LIBS=ON
logfile
1177 cases, 0 failed, t: 3m1s
PASS :white_check_mark:

gcc.Debug, NINJA_BUILD=true
logfile
1177 cases, 0 failed, t: 2m56s
PASS :white_check_mark:

clang.Debug -Dunity=OFF -Dsan=address, PARALLEL_TESTS=false, DEBUGGER=false
logfile
1176 cases, 0 failed, t: 6m5s
PASS :white_check_mark:

clang.Debug -Dunity=OFF -Dsan=undefined, PARALLEL_TESTS=false
logfile
1176 cases, 0 failed, t: 11m17s
PASS :white_check_mark:

Codecov Report

Merging #2931 into develop will decrease coverage by <.01%.
The diff coverage is 50%.

@@             Coverage Diff             @@
##           develop    #2931      +/-   ##
===========================================
- Coverage    69.38%   69.37%   -0.01%
===========================================
  Files          708      708
  Lines        56426    56425       -1
===========================================
- Hits         39152    39147       -5
- Misses       17274    17278       +4

Impacted Files
Coverage Δ

src/ripple/peerfinder/impl/Logic.h
43% <50%> (ø)
:arrow_up:

src/ripple/overlay/impl/OverlayImpl.cpp
29% <50%> (+0.04%)
:arrow_up:

src/ripple/ledger/impl/ApplyView.cpp
80% <0%> (-2.61%)
:arrow_down:

src/ripple/core/impl/Workers.cpp
98.94% <0%> (-1.06%)
:arrow_down:

src/ripple/app/main/Application.cpp
57.87% <0%> (-0.11%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5214b3c...43d0507. Read the comment docs.

Thank you for your submission. It will be reviewed soon and submitted for processing in CI.

Thank you for your submission. It will be reviewed soon and submitted for processing in CI.

@nbougalis @MarkusTeufelberger @alloyxrp @mDuo13 updated the default port to reflect #3037. This patch just affects the port assigned to ips and ips_fixed entries if not specified, it does not change the default ports listened on in rippled.cfg. After this any configurations w/ unspecified ports may result in connection errors if peers are still listening on the legacy port 51235

Thank you for your submission. It will be reviewed soon and submitted for processing in CI.

This has been superseded by #3235.


fix: Naming in web_compatibility assets

fix #2580

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Unable to select Collection in import dialog

Steps to reproduce

Search for a book on the import page
Select a book to import
Unable to select a collection to import to

Expected behavior
Able to select a collection to import to
Actual behavior

Logs
No response
Tankobon version
a281a1b
Operating system
Docker
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
[X] I have written a short but informative title.
[X] I have updated the app to the latest version.
[X] I filled out all of the requested information in this form.

Uh, that's weird. Can you show what's the response for the API requests?

What is weird is that it isn't hitting the collection endpoint

I guess it's because of some modifications I did on the selector component when I was making it support generic types. Will fix these days 👍🏻


Charm and Waystones compatibility

I currently have a modpack I'd be interested in taking your mod into. However I've noticed some things which don't have their xp tax flattened:
Charm: Grindstone disenchantment. Similar mechanic to the standalone mod you have cross compat with, so likely can be fixed in much the same way...? maybe? hopefully?
Waystones: Costs levels to transport between waystones. Tester says that they still tax you when transporting.
Would you be able to take a look at these, please?

Quickly looked into it, looks like Charm compat is doable.
Do you mean Fabric Waystones or Waystones (Fabric Edition)?
Because Fabric Waystones can be configured to use a flat XP cost (by setting cost_type to xp), so it feels a pretty pointless to add compatibility to that.

I put a prerelease with Charm compatibility here.
Lemme know about Waystones so I can make a proper release later.

Quickly looked into it, looks like Charm compat is doable. Do you mean Fabric Waystones or Waystones (Fabric Edition)? Because Fabric Waystones can be configured to use a flat XP cost (by setting cost_type to xp), so it feels a pretty pointless to add compatibility to that.

oh, um. the forge version please. I'll have to check the configs for waystones to see if that exists currently. in which case, sorry about that.
I'll see about testing the charm comp tomorrow when I'm available again. Thank you. :)

Just checked the configs for waystones, doesn't seem to have the option. it's based on levels that increase based on blocks traveled I believe.

oh, um. the forge version please

Dang it! :smile:
I expected Charm meant Fabric since Forge has the original Quark.
Forge compat will be an issue because Charm uses the ForgeGradle build system while I use Architectury and I have no idea if there's a way to compile one against the other. In the worst case I'd have to switch to ForgeGradle, which is a gruesome task (there's a reason I use Architectury).
This could take days or weeks, no ETA on that one.

well thats a frick. D: I'm sorry, I shoulda specified my modloader also, forgetting you've got both going.

I found a somewhat hacky workaround to get Charm going (by directly compiling against the Charm binaries).
Give it a try here.
Won't be as easy for Waystones I feel, still no ETA on that.

roger-roger

k, was able to basically do the same for Waystones too, here's the prerelease.
Technically that's it for this issue but I'll leave it open as a reminder for me to find a proper solution (and to add this for newer versions too).

Thanks a lot. I'll give it a go!

Will this pre-release be placed onto curseforge? it seems to be working. but if I'm to eventually update my pack I need it available on curseforge to be accepted I think.

I can upload it as an alpha or beta, not quite sure how CurseForge modpacks deal with that though...?

as long as it exists on curseforge I should be able to use it for my pack.
just alphas don't show in the launcher unless downloaded manually and then it detects it and shows the version or you allow alphas in the settings and then manually install one from the version list.
Beta would be more accessible and stuff, and people could get it if they need it, or "stick to the release, for stability" as some do.

Uploaded it as a beta just now, should soon be approved.

Will this come to Forge for 1.18.2 (for the waystones) or are old(er) mc versions not supported?

Ah, I never finished this, didn't I? Thanks for the reminder!
Looks like Charm is still stuck on 1.16, as is Lost Trinkets, so I forward-ported the Waystones compatibility to 1.17 - 1.19.
Get it while it's hot, on Modrinth or CurseForge of course.

I guess this issue can now be closed.
Let me know if Charm gets ported to newer versions so I can update Tax Free Levels accordingly!


transports.File stops logger without any error message

I'm trying to use transports.File to save log file in loop with logger. After several logs print out it stops to write log to file and print nothing in console without any error message.
Here is my test code:
import winston from 'winston'

const winstonConfig = {
  level: 'debug',
  transports: [
    new winston.transports.Console(),
    new winston.transports.File({
      filename:  'file/path/to/combined.log',
      maxsize: 10 * 1024 * 1024,
      maxFiles: 10
    })
  ]
}
let logger = winston.createLogger(winstonConfig)

for(let i=0; i<10000; i++){
  logger.debug(i)
}

Is it stdout buffer issue?
I'm using version 3.0.0-rc1 with node:8-alpine image in docker container

Hi,
Same case here on a raspberry pi3 with
"winston": "^3.0.0-rc1",
"winston-daily-rotate-file": "^2.0.0-rc.2"

I have 3 DailyRotateFile loggers with differents levels and a console logger in dev env.
I'm also logging a lot of stuff.
pi@raspberry:~ $ ls -ltah ~/.botctl/logs/*09
-rw-r--r-- 1 pi pi 56M févr.  9 21:56 /home/pi/.botctl/logs/combined.log.2018-02-09
-rw-r--r-- 1 pi pi 56M févr.  9 21:56 /home/pi/.botctl/logs/silly.log.2018-02-09
-rw-r--r-- 1 pi pi   0 févr.  9 07:51 /home/pi/.botctl/logs/error.log.2018-02-09

My config is the following
const consoleFormat = winston.format.combine(
  winston.format.colorize(),
  winston.format.timestamp(),
  winston.format.align(),
  winston.format.splat(),
  winston.format.printf((info) => {
    const ts = info.timestamp.slice(0, 19).replace('T', ' ');
    if (info.args) {
      return `${ts} [${info.level}]: ${info.message} ${(info.level > 3 && (Object.keys(info.args).length || Object.getOwnPropertyNames(info.args).length)) ? JSON.stringify(info.args, null, 2) : ''}`;
    } else {
      return `${ts} [${process.pid}] [${info.level}]: ${info.message}`;
    }
  })
);

const fileFormat = winston.format.combine(
  winston.format.timestamp(),
  winston.format.align(),
  winston.format.splat(),
  winston.format.printf((info) => {
    const ts = info.timestamp.slice(0, 19).replace('T', ' ');
    if (info.args) {
      return `${ts} [${process.pid}] [${info.level}]: ${info.message} ${(Object.keys(info.args).length || Object.getOwnPropertyNames(info.args).length) ? JSON.stringify(info.args, null, 2) : ''}`;
    } else {
      return `${ts} [${process.pid}] [${info.level}]: ${info.message}`;
    }
  })
);

winston.addColors(logLevels);

const LOG_LEVEL = process.env.NODE_LOG_LEVEL || 'verbose';
const CONSOLE_LEVEL = process.env.NODE_CONSOLE_LEVEL || 'info';

const logger = winston.createLogger({
  level: LOG_LEVEL,
  levels: logLevels.levels,
  format: fileFormat,
  transports: [
    //
    // - Write all logs error (and below) to `error.log`.
    // - Write all silly logs (and below) to silly.log.
    // - Write all %level% logs (and below) to main.log
    //
    new DailyRotateFile({ filename: path.join(LOGS_DIR, 'error.log'), level: 'error', handleExceptions: true }),
    new DailyRotateFile({ filename: path.join(LOGS_DIR, 'silly.log'), level: 'silly' }),
    new DailyRotateFile({ filename: path.join(LOGS_DIR, 'combined.log'), level: LOG_LEVEL })
  ]
});

if (process.env.NODE_ENV !== 'production') {
  logger.add(new winston.transports.Console({
    format: consoleFormat,
    colorize: true,
    level: CONSOLE_LEVEL
  }));
}
logger.exitOnError = false;

I have noticed that my file logger stops at 21:56 and my console logger continued until 22:43.
Since then nothing happen in logs or my modules.
I need to restart my services with cron to bypass the issue so far.
I also notice that the error file is empty.
I can't tell if the issue is linked with some specific actions in my programs.
How can i provide more traces related to winston ?
Can i provide a parameter to limit file size or rotate by hours instead of days ?
Thanks

I just ran into the same issue as @bouchezb and my setup is effectively identical:
"winston": "^3.0.0-rc1",
"winston-daily-rotate-file": "^2.0.0-rc.2"

I similarly use Console and DailyRotateFile transports (although I only have a single DailyRotateFile open). The transports are almost entirely built of default settings.
The format settings I use are timestamp() and a custom formatter that makes use of printf as shown in the documentation.
Anyone have any ideas as to what's going on?

Hi,
I haven't found a solution yet (better than cron restart).
I recently tried an hour rotation and the issue happens with higher frequency.
Probably during rotation process.

@bouchezb

Probably during rotation process.

Yes, I believe you're correct.
I noticed that it was possible to hook into the stream events in the main README.md:

You can listen to the open, close, error, and finish events generated by the underlying stream. You can also listen for the rotate custom event. The rotate event will pass two parameters to the callback (oldFilename, newFilename).

So... I implemented them:
// DEBUGGING.
rotateFileTransport.on('close', function () {
    console.trace("Transport Stream Closing?!");
});

rotateFileTransport.on('finish', function () {
    console.trace("Transport Stream Finished?!");
});

rotateFileTransport.on('error', function (err: Error) {
    console.trace("Error with Transport [Stream?]?!");
    console.dir(err);
});

rotateFileTransport.on('open', function (fd: any) {
    console.trace("Transport Stream Opened?!");
    console.dir(fd);
});

rotateFileTransport.on('rotate', function (oldFile: any, newFile: any) {
    console.trace("Rotating Files?!");
    console.dir(oldFile);
    console.dir(newFile);
});

[I used console.dir/trace in case it wasn't just the File writing Transport (winston-daily-rotate-file), but the entire Logger itself that failed.]
I then played the waiting game. At some point a log entry was triggered at 02:25 UTC and the following flow of output occurred:
Express Endpoint Processing Error
The following error occurred. The important part is the timestamp (specifically 02:25:29):
2018-02-23T02:25:29.691Z [error]: Stack: Error
    at DoWork (/app/site/server.js:95:33)
    at HandleEndpoint (/app/site/server.js:175:17)
    at Layer.handle [as handle_request] (/app/site/node_modules/express/lib/router/layer.js:95:5)
    at next (/app/site/node_modules/express/lib/router/route.js:137:13)
    at jsonParser (/app/site/node_modules/body-parser/lib/types/json.js:118:7)
    at Layer.handle [as handle_request] (/app/site/node_modules/express/lib/router/layer.js:95:5)
    at next (/app/site/node_modules/express/lib/router/route.js:137:13)
    at Route.dispatch (/app/site/node_modules/express/lib/router/route.js:112:3)
    at Layer.handle [as handle_request] (/app/site/node_modules/express/lib/router/layer.js:95:5)
    at /app/site/node_modules/express/lib/router/index.js:281:22

On Rotate Triggered
Up next is the Rotate event. The source is, unsurprisingly, here. This occurs after both destroy is called on the old writeStream and a new one is generated with fs.createWriteStream.
The filenames output were as expected.
Trace: Rotating Files?!
    at DailyRotateFile.<anonymous> (/app/site/build/logger.js:71:13)
    at emitTwo (events.js:106:13)
    at DailyRotateFile.emit (events.js:194:7)
    at EventEmitter.<anonymous> (/app/site/node_modules/winston-daily-rotate-file/daily-rotate-file.js:93:18)
    at emitTwo (events.js:111:20)
    at EventEmitter.emit (events.js:194:7)
    at Object.<anonymous> (/app/site/node_modules/file-stream-rotator/FileStreamRotator.js:441:24)
    at DailyRotateFile.log (/app/site/node_modules/winston-daily-rotate-file/daily-rotate-file.js:134:24)
    at DailyRotateFile.TransportStream._write (/app/site/node_modules/winston-transport/index.js:88:17)
    at doWrite (_stream_writable.js:329:12)
'/app/logs/2018-02-22-main.log'
'/app/logs/2018-02-23-main.log'

On Close Triggered
The starting point of this stack [fs.js:1973] looks a little odd at first (it's in a ReadStream function), but the WriteStream version merely points to the ReadStream one. My best guess here is that this triggered by destroy but somehow pushed to the next tick...?
This is the point that I started finding the reported call-stacks oddly equal in length. It turns out, there's a default stackTraceLimit that appears to be set to 10. Setting it to ∞ will remove the limit altogether. I will try updating my code to see if it helps provide further insights. In the meantime...
Trace: Transport Stream Closing?!
    at DailyRotateFile.<anonymous> (/app/site/build/logger.js:57:13)
    at emitNone (events.js:91:20)
    at DailyRotateFile.emit (events.js:188:7)
    at EventEmitter.<anonymous> (/app/site/node_modules/winston-daily-rotate-file/daily-rotate-file.js:77:18)
    at emitNone (events.js:86:13)
    at EventEmitter.emit (events.js:188:7)
    at WriteStream.<anonymous> (/app/site/node_modules/file-stream-rotator/FileStreamRotator.js:497:15)
    at emitNone (events.js:86:13)
    at WriteStream.emit (events.js:188:7)
    at fs.js:1973:14

On Open Triggered
My best guess is that this was triggered by the call to createWriteStream that generated the new file. The file descriptor output (11) was the same file descriptor as the [theoretically?] just-closed file.
Trace: Transport Stream Opened?!
    at DailyRotateFile.<anonymous> (/app/site/build/logger.js:67:13)
    at emitOne (events.js:96:13)
    at DailyRotateFile.emit (events.js:191:7)
    at EventEmitter.<anonymous> (/app/site/node_modules/winston-daily-rotate-file/daily-rotate-file.js:89:18)
    at emitOne (events.js:96:13)
    at EventEmitter.emit (events.js:191:7)
    at WriteStream.<anonymous> (/app/site/node_modules/file-stream-rotator/FileStreamRotator.js:506:15)
    at emitOne (events.js:101:20)
    at WriteStream.emit (events.js:191:7)
    at WriteStream.<anonymous> (fs.js:2043:10)
11

On Finish Triggered
I'm not entirely sure where this one came from, but it looks like finishMaybe is called once writing completes. Perhaps this occurs immediately after writing to the newly created file for the first time?
Trace: Transport Stream Finished?!
    at DailyRotateFile.<anonymous> (/app/site/build/logger.js:60:13)
    at emitNone (events.js:91:20)
    at DailyRotateFile.emit (events.js:188:7)
    at EventEmitter.<anonymous> (/app/site/node_modules/winston-daily-rotate-file/daily-rotate-file.js:81:18)
    at emitNone (events.js:86:13)
    at EventEmitter.emit (events.js:188:7)
    at WriteStream.<anonymous> (/app/site/node_modules/file-stream-rotator/FileStreamRotator.js:500:15)
    at emitNone (events.js:91:20)
    at WriteStream.emit (events.js:188:7)
    at finishMaybe (_stream_writable.js:510:14)

On Close Triggered [again]
This is the same callstack (top) as the last Closed event. My guess is that this is now the new file being closed. It seems that it's opened, written to once, and then immediately finalized and closed. This obviously isn't correct. No idea at present why this occurs (and am not 100% confident in this analysis).
Trace: Transport Stream Closing?!
    at DailyRotateFile.<anonymous> (/app/site/build/logger.js:57:13)
    at emitNone (events.js:91:20)
    at DailyRotateFile.emit (events.js:188:7)
    at EventEmitter.<anonymous> (/app/site/node_modules/winston-daily-rotate-file/daily-rotate-file.js:77:18)
    at emitNone (events.js:86:13)
    at EventEmitter.emit (events.js:188:7)
    at WriteStream.<anonymous> (/app/site/node_modules/file-stream-rotator/FileStreamRotator.js:497:15)
    at emitNone (events.js:86:13)
    at WriteStream.emit (events.js:188:7)
    at fs.js:1973:14

In the first part of this breakdown I showed the timestamp reported by the event (02:25:29). When listing the files in the log directory, I see the following:
-rw-r--r-- 1 root root  865 Feb 23 02:25 2018-02-23-main.log

The important bit is the last modified time field: 02:25. It appears that the file is opened, written to, and then immediately closed. This is all triggered during the first event when file rotation occurs.
I suspect that the same thing (or very similar) may be happening for people using the main File Transport.
At this point I wish I'd added some timestamps to the logging. I'll add that and remove the stack trace limits to see what extra information I can glean from these events.

At this point I wish I'd added some timestamps to the logging. I'll add that and remove the stack trace limits to see what extra information I can glean from these events.

I made those adjustments and modified some settings to make the file rotation occur every 2 minutes (and set FileStreamRotator to verbose). I immediately reproduced the issue.
Here is what I got as output:
On Open Triggered
This is the initial file opening event. The number (11) at the end is the file descriptor of the opened log file.
Trace: [2018-02-23T20:39:39.886Z] Transport Stream Opened?!
    at DailyRotateFile.<anonymous> (/app/site/build/logger.js:67:13)
    at emitOne (events.js:96:13)
    at DailyRotateFile.emit (events.js:191:7)
    at EventEmitter.<anonymous> (/app/site/node_modules/winston-daily-rotate-file/daily-rotate-file.js:89:18)
    at emitOne (events.js:96:13)
    at EventEmitter.emit (events.js:191:7)
    at WriteStream.<anonymous> (/app/site/node_modules/file-stream-rotator/FileStreamRotator.js:506:15)
    at emitOne (events.js:101:20)
    at WriteStream.emit (events.js:191:7)
    at WriteStream.<anonymous> (fs.js:2043:10)
    at FSReqWrap.oncomplete (fs.js:114:15)
11

Log Event
One log event was triggered.
2018-02-23T20:42:01.493Z [info]: Received Request.

File Rotation Event
That log event triggered the logic for the file rotation (I had waited more than the requisite 2min for file rotation). The first line is some of FileStreamRotator's verbose output.
2018-02-23T20:42:01.493Z '[FileStreamRotator] Changing logs from %s to %s' '/app/logs/201802232038-main.log' '/app/logs/201802232042-main.log'
Trace: [2018-02-23T20:42:01.494Z] Rotating Files?!
    at DailyRotateFile.<anonymous> (/app/site/build/logger.js:71:13)
    at emitTwo (events.js:106:13)
    at DailyRotateFile.emit (events.js:194:7)
    at EventEmitter.<anonymous> (/app/site/node_modules/winston-daily-rotate-file/daily-rotate-file.js:93:18)
    at emitTwo (events.js:111:20)
    at EventEmitter.emit (events.js:194:7)
    at Object.<anonymous> (/app/site/node_modules/file-stream-rotator/FileStreamRotator.js:441:24)
    at DailyRotateFile.log (/app/site/node_modules/winston-daily-rotate-file/daily-rotate-file.js:134:24)
    at DailyRotateFile.TransportStream._write (/app/site/node_modules/winston-transport/index.js:88:17)
    at doWrite (_stream_writable.js:329:12)
    at writeOrBuffer (_stream_writable.js:315:5)
    at DailyRotateFile.Writable.write (_stream_writable.js:241:11)
    at DerivedLogger.ondata (_stream_readable.js:557:20)
    at emitOne (events.js:101:20)
    at DerivedLogger.emit (events.js:191:7)
    at readableAddChunk (_stream_readable.js:178:18)
    at DerivedLogger.Readable.push (_stream_readable.js:136:10)
    at DerivedLogger.Transform.push (_stream_transform.js:128:32)
    at DerivedLogger._transform (/app/site/node_modules/winston/lib/winston/logger.js:218:8)
    at DerivedLogger.Transform._read (_stream_transform.js:167:10)
    at DerivedLogger.Transform._write (_stream_transform.js:155:12)
    at doWrite (_stream_writable.js:329:12)
    at writeOrBuffer (_stream_writable.js:315:5)
    at DerivedLogger.Writable.write (_stream_writable.js:241:11)
    at DerivedLogger.log (/app/site/node_modules/winston/lib/winston/logger.js:150:10)
    at /app/site/build/search.js:55:37
    at step (/app/site/build/search.js:38:23)
    at Object.next (/app/site/build/search.js:19:53)
    at /app/site/build/search.js:13:71
    at __awaiter (/app/site/build/search.js:9:12)
    at DoAsyncAwaitStuff (/app/site/build/search.js:50:12)
    at Layer.handle [as handle_request] (/app/site/node_modules/express/lib/router/layer.js:95:5)
    at next (/app/site/node_modules/express/lib/router/route.js:137:13)
    at /app/site/node_modules/body-parser/lib/read.js:130:5
    at invokeCallback (/app/site/node_modules/raw-body/index.js:224:16)
    at done (/app/site/node_modules/raw-body/index.js:213:7)
    at IncomingMessage.onEnd (/app/site/node_modules/raw-body/index.js:273:7)
    at emitNone (events.js:86:13)
    at IncomingMessage.emit (events.js:188:7)
    at endReadableNT (_stream_readable.js:975:12)
    at _combinedTickCallback (internal/process/next_tick.js:80:11)
    at process._tickCallback (internal/process/next_tick.js:104:9)
'/app/logs/201802232038-main.log'
'/app/logs/201802232042-main.log'

More Log Events
Two more log events were triggered. They are downstream of (were triggered by) the previous log event.
2018-02-23T20:42:01.506Z [info]: Async processing 1...
2018-02-23T20:42:01.533Z [info]: Async processing 2...

On Close Triggered
The close event was triggered, 68ms after the last log statement.
Trace: [2018-02-23T20:42:01.601Z] Transport Stream Closing?!
    at DailyRotateFile.<anonymous> (/app/site/build/logger.js:57:13)
    at emitNone (events.js:91:20)
    at DailyRotateFile.emit (events.js:188:7)
    at EventEmitter.<anonymous> (/app/site/node_modules/winston-daily-rotate-file/daily-rotate-file.js:77:18)
    at emitNone (events.js:86:13)
    at EventEmitter.emit (events.js:188:7)
    at WriteStream.<anonymous> (/app/site/node_modules/file-stream-rotator/FileStreamRotator.js:497:15)
    at emitNone (events.js:86:13)
    at WriteStream.emit (events.js:188:7)
    at fs.js:1973:14
    at FSReqWrap.oncomplete (fs.js:114:15)

On Open Triggered
The open event was triggered 1ms later. Note that the file descriptor is the same.
Trace: [2018-02-23T20:42:01.602Z] Transport Stream Opened?!
    at DailyRotateFile.<anonymous> (/app/site/build/logger.js:67:13)
    at emitOne (events.js:96:13)
    at DailyRotateFile.emit (events.js:191:7)
    at EventEmitter.<anonymous> (/app/site/node_modules/winston-daily-rotate-file/daily-rotate-file.js:89:18)
    at emitOne (events.js:96:13)
    at EventEmitter.emit (events.js:191:7)
    at WriteStream.<anonymous> (/app/site/node_modules/file-stream-rotator/FileStreamRotator.js:506:15)
    at emitOne (events.js:101:20)
    at WriteStream.emit (events.js:191:7)
    at WriteStream.<anonymous> (fs.js:2043:10)
    at FSReqWrap.oncomplete (fs.js:114:15)
11

On Finish Triggered
The finish event was triggered 12ms after open.
Trace: [2018-02-23T20:42:01.614Z] Transport Stream Finished?!
    at DailyRotateFile.<anonymous> (/app/site/build/logger.js:60:13)
    at emitNone (events.js:91:20)
    at DailyRotateFile.emit (events.js:188:7)
    at EventEmitter.<anonymous> (/app/site/node_modules/winston-daily-rotate-file/daily-rotate-file.js:81:18)
    at emitNone (events.js:86:13)
    at EventEmitter.emit (events.js:188:7)
    at WriteStream.<anonymous> (/app/site/node_modules/file-stream-rotator/FileStreamRotator.js:500:15)
    at emitNone (events.js:91:20)
    at WriteStream.emit (events.js:188:7)
    at finishMaybe (_stream_writable.js:510:14)
    at afterWrite (_stream_writable.js:384:3)
    at onwrite (_stream_writable.js:374:7)
    at fs.js:2110:5
    at FSReqWrap.wrapper [as oncomplete] (fs.js:2077:5)

On Close Triggered
The close event was triggered again, 10ms after the last open.
Trace: [2018-02-23T20:42:01.624Z] Transport Stream Closing?!
    at DailyRotateFile.<anonymous> (/app/site/build/logger.js:57:13)
    at emitNone (events.js:91:20)
    at DailyRotateFile.emit (events.js:188:7)
    at EventEmitter.<anonymous> (/app/site/node_modules/winston-daily-rotate-file/daily-rotate-file.js:77:18)
    at emitNone (events.js:86:13)
    at EventEmitter.emit (events.js:188:7)
    at WriteStream.<anonymous> (/app/site/node_modules/file-stream-rotator/FileStreamRotator.js:497:15)
    at emitNone (events.js:86:13)
    at WriteStream.emit (events.js:188:7)
    at fs.js:1973:14
    at FSReqWrap.oncomplete (fs.js:114:15)

[Note]
Several events quickly followed (<200ms) the final close event report. Those events were not written to the log file - only the three log messages shown above made it into the new log file.

Removing the limit on call stack depth didn't reveal much extra with respect to the open/close/finish event callbacks. The rotate event, however, revealed quite a bit of information. Perhaps it would be helpful to someone who understands how Winston injects itself into the standard NodeJS Stream handling?
@indexzero, any thoughts here? If you've not seen these Issues yet, it seems that any Transport that attempts to close one file stream and open another (as the core File Transport does when you set a max size) will open the new file stream in such a manner that it is immediately closed. Is there a test that covers this scenario? This feels like a pretty serious showstopper for 3.0.0...

One more note: I have been testing with Node 7.8.0. The file names and line numbers in the call stacks in my last two posts will resolve correctly with files in this commit of the main NodeJS repo.

@bouchezb The winston-daily-rotate-file issue was identified and has been solved! Give it a shot by installing winston-daily-rotate-file@next.
While this good news is specifically related to the winston-daily-rotate-file Transport and not the File Transport, the issue that affected winston-daily-rotate-file could also be affecting the File Transport.
@billiebbb and @beac0n two questions for you:

What versions of node/npm are you running?
Can you tell if the logger stops working after a file rotation occurs?

I ask the second question because internal stream event bubbling with winston-daily-rotate-file is what caused the Transport to close and unpipe itself. This happened during the file rotation process. Some logs might make it into the newly created file before it was closed if they were reported quickly enough. Given the tight loop in @billiebbb's example code, it might be the case that those logs are buffered and then several files created before the File transport has some time to react to its first internal file sending an "I'm done" message (close or finish or something...).

@ericdrobinson thanks for the fix.
I did the update but i'm still experiencing some issues.
I think this is more related to winston core module than winston-daily-rotate-file because crashes seems now to occur in a more random way than before.
I'll open a ticket if i can find some new revelant clues.
Thanks again for your support.
Regards.

I think this is more related to winston core module than winston-daily-rotate-file because crashes seems now to occur in a more random way than before.
I'll open a ticket if i can find some new revelant clues.

That would probably be best. This issue is specifically about the File transport stopping the logger. Crashes would be another issue and it would be good to open a different issue (or comment on one that already exists) to keep the conversation focused.
@indexzero What settings/event registrations would you recommend adding when attempting to figure out issues in winston@3?

Also seeing this issue on 3.0.0-rc3
I run the application and it works fine for some time, but then it fails to log to console or the log files with no exception or error generated - a "silent fail"
Is there any work being done on this?

@rcoedo commit fixes the issue but there is still an issue with formatting which I think is related to this.
const winston = require('winston')

const winstonConfig = {
  level: 'debug',
  transports: [
    new winston.transports.Console({
      format: winston.format.printf(info => `${info.level}: ${info.message}`)
    }),
    new winston.transports.File({
      filename: 'winston.log',
      maxsize: 10 * 1024 * 1024,
      maxFiles: 10,
      format: winston.format.printf(info => `${info.level}: ${info.message}`)
    })
  ]
}
const logger = winston.createLogger(winstonConfig)

for (let i = 0; i < 10000; i++) {
  logger.debug(i)
}

Produces this output to a file:
....
debug: 2600
debug: 2601
debug: 2602
debug: 2603
debug: 2604
debug: 2605
debug: 2606
{"message":2607,"level":"debug"}
{"message":2608,"level":"debug"}
{"message":2609,"level":"debug"}
{"message":2610,"level":"debug"}
{"message":2611,"level":"debug"}
{"message":2612,"level":"debug"}
{"message":2613,"level":"debug"}
{"message":2614,"level":"debug"}
{"message":2615,"level":"debug"}
{"message":2616,"level":"debug"}
{"message":2617,"level":"debug"}
{"message":2618,"level":"debug"}
{"message":2619,"level":"debug"}
{"message":2620,"level":"debug"}
{"message":2621,"level":"debug"}
debug: 2622
debug: 2623
debug: 2624
debug: 2625
debug: 2626
debug: 2627
debug: 2628
.....

Output in the console is formatted correctly.

@jansteuer I can reproduce the behavior. When the stream.write tell us to wait for the drain event, the following 15 lines receive a non formatted message for some reason. I tried to find why but I failed.
I believe this is related to how the Logger handles the transports but I'm not sure. Maybe someone with some expertise in winston can guide us to finally fix the file transport 😃

I implemented @rcoedo's fix, and the logger seemed stable for a few days, but today all of the logging for my application disappeared.  There are no exceptions generated anywhere that I can see, and I can't find a way to reproduce it.  Anybody at WinstonJS have an idea?
The current workaround I am trying is to forcibly delete and reinstantiate the logger every 30 minutes.

Hi Everyone, my team is also able to reproduce this issue with the latest version of<EMAIL_ADDRESS>It's strange because when we first initialize our logger and run our application, everything is fine, or it seems... We log every time we receive a message from IBM MQLight and we noticed once around 600 messages (both from console and physical log file) winston inexplicably stops even though the application continues to run, just no logging at all?...
We know the issue is coming from winston because we modified this bit of code in our custom logging class library that instantiates winston to use fs.createWriteStream directly and it always works:
`
// winston
this.logger = createLogger({
exitOnError: false,
format: format.json(),
transports: [
new transports.File({
tailable: true,
zippedArchive: false,
handleExceptions: true,
filename: path.resolve(options.logDir, options.fileName),
maxsize: options.maxsize,
maxFiles: options.maxFiles
})
]
});
const write = (msg) => {
this.logger.info(msg);
};
// using native fs
this.logger = fs.createWriteStream(path.resolve(options.logDir, options.fileName));
const write = (msg) => {
this.logger.write(msg + "\n");
};
`
Does anyone have any solution as to why its stops randomly?

Is it possible that this is related to #1144? That was fixed 8 days ago or so and merged into master 9 in PR #1291. On the other hand<EMAIL_ADDRESS>was released before that (13 days ago).
Perhaps test against master?

@ericdrobinson Hmm, I was really hopeful.... I pulled the latest version from master in Winston as you recommended about an hour ago then manually dropped that version and referenced it in my code directly. Sadly, I received the same results.
My test involved dumping 10000 messages at <5ms. After about 700 or 800 received and logged messages, Winston logging for file and console stopped. Swapped over my code to use fs.createWriteStream native version and ran the exact same test, results showed precisely 10000 messages were logged.
Does Winston close the stream or something? The only difference I can see I'm doing with my little version of fs.createWriteStream in my test is I never close my stream or have any drain management.

@ejaweb I've no idea. You could start digging into this yourself by adding some debug logging to your Winston setup to begin tracking things down. I did this previously for a different bug that was apparently specific to winston-daily-rotate-file. Here's the description of what I did. Note that you'll want to set your stack trace limit to Infinity to properly see the full context within which you get your callbacks.
This bug report is missing good debug info from someone using the File Transport. My comments turned out to be related to a different issue.
As you have a 100% repro-case, perhaps you could add in some debug output and provide further context?

@ericdrobinson Oh man interesting news! Before I decided to make any additional changes to my code (to start tracking down the bug), I decided to try winston-daily-rotate-file to see if I could re-produce the same error... I can't!!! It seems winston-daily-rotate-file contains the fix because it works perfectly! I tested multiple times as well. I think for now my team will be using this instead of winston's default Transports.File. Thanks!

@indexzero Shouldn't this issue be Closed now? It's referenced as "Fixed" in the release notes for rc6...

I think this still happens when using the tailable: true option.

I had same issue, today. What happened for me is the follwing

Transport Console
Transport File

In my project I had deleted the folder containing the log files.
In that case, winston was correctly logging stuff until it get to a specific point in the console! Always the same, don't know why.
I fixed this by creating the containing folder. As soon as winston found a file to write in, console output was back to normal.
Hope this helps.

@dlarr Yes I have observed the same thing myself. It seems to be caused by missing error handling code in winston. By my reckoning, when the file stream cannot be created because the parent folder is missing, the file transport is allowed to continue in a zombie state until the PassThrough fills up. At the end a pause() is called and waits for a drain that will never happen.

In the particular case of @dlarr and me error handling in file.js!_createStream() and file.js!stat() should probably be looked at.

In our project we have a derived logger that creates a Console transport and a File transport. If the logger is run in an environment where the parent folder of the file transport is missing, the logger stops logging as described above. Also the Console transport stops. Our workaround is to not let our derived logger to create the file transport if the parent folder of the log file is missing.

Hopefully the case of tailable: true has also been fixed now, thanks to #1420.   If someone could confirm or deny, testing against master, that would be awesome —  would love to see this issue closed.  The aforementioned fix will go out in the next release, which hopefully should be published very soon.

I can confirm , the  fix in master branch is working fine after setting tailable flag to true. Looking forward someone to publish this in npm.
maxsize: 100000*1024,   tailable: true

Going to go ahead and close this at last (3.1.0 was pushed to npm recently), but if anyone can reliably reproduce issues with the core File transport (or other core transports), please open a new issue and we'll work to get to the bottom of it.  Thanks to everyone who contributed to documenting and solving this issue!

So, I'm using Winston 3.10.0 and  Winston-daily-rotate-file 4.7.1 and have run into an issue very similar to this.  My app has 5 asynchronous tasks to perform at startup and just as it's getting going, the logs stop abruptly.  Console is not affected, but in production I don't keep console running. I had hoped that the daily rotate would trigger a reset and the logs would start being written, but this didn't happen.  It's technically intermittent but only because it doesn't happen sometimes. I'm revving to Winston 3.11.0.
Does anyone have any ideas how to debug this? If I turn off tailable will that help?  I find files on Windows don't tail anyway, and I have a final flush before the app quits so maybe that's not a big loss.


fix spacing of footer on firefox & some other browsers

the page needed more room for refine button at the bottom on mobile, and the margin simply did not work on firefox

Coverage remained the same at 24.394% when pulling a9b122612a62ce83d58ff64b8f3116e08f667645 on Kiloutre:patch-8 into 518f59d089a9a304d388cfe2fd03b25828f7742c on NyaaPantsu:dev.


Fixed deprecation warnings for Ansible 2.x

Fixed https://github.com/FloeDesignTechnologies/ansible-haproxy/issues/41

Sorry for the delay and lack of actions. We are finding that we are not using this role anymore and cannot commit to its maintenance. We are looking for an individual or organization to take over. Please see #53 if you are interested.


Create PULL_REQUEST_TEMPLATE.md

A first version, we'll add more things as we go. As right now master doesn't launch up the server due to a regression, this makes it really hard to work in the fastlane/ci code base.

That's a great idea 👍 Will do


Update examples to use Keras where possible

We should consider waiting on this until we finish refactoring the converter, unless we can do it with the current converter (related https://github.com/mortendahl/tf-encrypted/issues/297)

Not sure I follow. Most of the examples are not using the converter.

Duplicate of #541


Sonarcloud scan results

My team and I have been reviewing OpenPilot as part of our Semester project at University and part of this review was running an automated scanning tool on OpenPilot's source code. It's conclusions can be found here:
https://sonarcloud.io/summary/overall?id=Rafterman29_openpilot
We have noted several key vulnerabilities including CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-326: Inadequate Encryption Strength, CWE-259: Use of Hard-coded Password, CWE-327: Use of a Broken or Risky Cryptographic Algorithm, CWE-401: Missing Release of Memory after Effective Lifetime, and more as listed in the SonarCloud scan linked above. Anyone is free to email me at<EMAIL_ADDRESS>for any more specific questions or direct access to my team's private repository in regards to our software review for this course.

For further review of the project we have also created Design Documentation, Assurance Cases, Software Security Engineering diagrams (including Misuse cases), and more documentation that can all be found within our now public repository at: https://github.com/chadknowlton/PrivateOpenPilotRepo
Again, feel free to reach out to me at<EMAIL_ADDRESS>if there are any questions. I wanted to supply our entire repository in case it is of use for anyone working on these security enhancements in the future.

Quickly looked over that scan result, but didn't see anything concerning. Do you think there is anything in those results that is actually relevant? Feel free to make the rest of your report public.
Between all the false positives it found two memcpy issues in boardd. One of them is already fixed.

(fixed) https://sonarcloud.io/project/issues?id=Rafterman29_openpilot&open=AX0_THL8gvHzTIyGNIWv&resolved=false&types=BUG
@briskspirit Is this one still relevant? https://sonarcloud.io/project/issues?id=Rafterman29_openpilot&open=AX0_THL8gvHzTIyGNIWw&resolved=false&types=BUG

Our main concerns are listed in our CodeAnalysis.md document:
https://github.com/chadknowlton/PrivateOpenPilotRepo/blob/main/CodeAnalysis.md
But all of the issues we found (that aren't false positives) seem to be relatively quick changes. For instance in athnad.py there is the following code snippit:
'upload_id = hashlib.sha1(str(item).encode()).hexdigest()'
SHA-1 is depricated and is no longer secure so it could be quickly replaced with SHA-256 to have a more secure hashing algorithm.
You are correct in saying that, for the most part, there isn't much that is overly concerning. We mostly wanted to bring up our results due to the quick-fix nature of any of the issues that we did find. However, whenever you have the time feel free to look at the document I linked and let me know what you think.

@briskspirit Is this one still relevant? https://sonarcloud.io/project/issues?id=Rafterman29_openpilot&open=AX0_THL8gvHzTIyGNIWw&resolved=false&types=BUG

No, tail_size is never will be bigger than tail buffer.

@briskspirit I assume it can happen if the USB packet is malformed, which is why the scanner triggered? Maybe we should put an assert before the memcpy so it just crashes instead of silently memcpying outside the buffer.

@pd0wm it is also not really possible as it depends on max USB frame size of 64 bytes, but I will add assertion to be safe.


[SPARK-31090] Revert SPARK-25457 "IntegralDivide returns data type of the operands"

What changes were proposed in this pull request?

Why are the changes needed?

There is no standard requiring that div must return the type of the operand, and always returning long type looks fine. This is kind of a cosmetic change and we should avoid it if it breaks existing queries. This is similar to reverting TRIM function parameter order change.
Does this PR introduce any user-facing change?

Yes, change the behavior of div back to be the same as 2.4.
How was this patch tested?

N/A

@mgaido91 @maropu @dongjoon-hyun @HyukjinKwon

Test build #119467 has started for PR 27835 at commit 7414359.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/24199/
Test PASSed.

Test build #119467 has finished for PR 27835 at commit 7414359.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/119467/
Test FAILed.

Test build #119715 has started for PR 27835 at commit 849a7e3.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/24444/
Test PASSed.

Test build #119715 has finished for PR 27835 at commit 849a7e3.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/119715/
Test PASSed.

cc @rxin since he is the release manager for 3.0.0 (Also, cc @gatorsmile )

Merged to master and branch-3.0.


New package: ThreadsX v0.1.0

Registering package: ThreadsX
Repository: https://github.com/tkf/ThreadsX.jl
Created by: @tkf
Version: v0.1.0
Commit: 46ed8e8670e381e466791ef9d767efe66a13ae29
Reviewed by: @tkf
Reference: https://github.com/tkf/ThreadsX.jl/issues/81#issuecomment-599338614

[noblock]
ping?


Add configurable padding before label

When a call number is left justified it prints all the way at the edge of the label
See attached file for details
When a call number is left justified it prints all the way at the edge of the label .docx

I am having this issue as well.
labelTest.pdf

I hope it's enough to add a 0.05in margin. Would rather not make it configurable unless absolutely necessary.

Hi Josh,
I think libraries will want to choose left-justify margins. The left side if the label often-times wraps on the side of the book spine, so there needs to be enough space to allow that. For example, one left-justifies .2
Thank you for investigating this,
Maggie

We're now supporting a configurable padding before the label text. Hope that resolves this issue.


Fixed a voter guide bug

Retrieving all voter guides filtered by organization_we_vote_id method returning All voter guides without filter(Two functions have same name  in voter_guides/models.py, Python does not support function overloading)

👍