-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: respect Winston Formatters #548
Conversation
Codecov Report
@@ Coverage Diff @@
## master #548 +/- ##
==========================================
+ Coverage 94.64% 94.74% +0.10%
==========================================
Files 7 7
Lines 672 685 +13
Branches 49 52 +3
==========================================
+ Hits 636 649 +13
- Misses 35 36 +1
+ Partials 1 0 -1
Continue to review full report at Codecov.
|
@liboz, could you amend your commit to follow conventional commits? See conventionalcommits.org |
49d31aa
to
7c6069f
Compare
@simonz130 Done |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@liboz Thanks for the PR. It seems like this PR is breaking the existing functionality please refer the below quick start example:
const loggingWinston = new LoggingWinston();
const logger = winston.createLogger({
level: 'info',
transports: [
loggingWinston,
],
});
logger.info('shields at 99%');
Output in Google Cloud Console:
Before applying the changes:
{
...
jsonPayload: {
message: 'shields at 99%',
...
}
...
}
After applying this changes:
{
...
jsonPayload: {
message: '{"message":"shields at 99%","level":"info"}' ,
...
}
...
}
you can't use info[MESSAGE]
always need to check if format is applied than use the same, while in normal case need to use message
.
@laljikanjareeya You're right that in that specific example it would return in the format you specified. However, that simply replicates the behavior in the rest of the winston ecosystem. Wouldn't the correct thing to do be to update the quick start example to use one of the default formatters winston provides? For example, If that's considered problematic, do you think it makes more sense to allow a formatter be passed in and have the plain message be the default formatter? |
@laljikanjareeya I changed it so that by default it uses just plain "message". However, it also allows one to pass in their own custom formatter into the logger. |
Taking a look this week |
Hi @liboz , thanks for your contribution. We'd like to get this in for you soon. I pulled your PR to review your changes, but the log was not formatted. Perhaps I'm not using your fix as intended. Can you extend the test in system-test/logging-winston to demonstrate your changes, i.e. : it('should work correctly with winston formats', async () => {
const MESSAGE = 'A message that should be padded';
const start = Date.now();
const LOG_NAME = logName('logging_winston_system_tests_2');
const logger = winston.createLogger({
transports: [new LoggingWinston({logName: LOG_NAME})],
format: winston.format.combine(
winston.format.colorize(),
winston.format.padLevels(),
// TODO: add your format configs here or write a similar test for it
),
});
logger.error(MESSAGE);
const [entry] = await pollLogs(
LOG_NAME,
start,
1,
WRITE_CONSISTENCY_DELAY_MS
);
const data = entry.data as {message: string};
assert.strictEqual(data.message, ` ${MESSAGE}`);
}); Note: to run system tests in this repo make sure you've set GCLOUD_PROJECT and GOOGLE_APPLICATION_CREDENTIALS |
@nicoleczhu As I mentioned earlier, I changed it so that this now lets you pass in a custom formatter through the constructor. If one does not do that, the default for
The work around would be to instead do something like this and pass it in through the constructor of
If the compatibility that @laljikanjareeya wants is required, I don't think there is an easier way. However, I think if a doc update could happen where people are directed to use a normal formatter like |
@liboz I see what you're saying. Let's keep the default Can you add a test to showcase your extension? I can't do it directly as I can't edit your remote branch. Something along the lines of |
@nicoleczhu Done |
@liboz I tried to merge but it looks like this PR is still breaking CI. See Running it locally, I'm getting: {
insertId: "..........3s1NuTHIp1WdASZcRYqxbC"
jsonPayload: {
metadata: {0}
message: "undefined"
}
resource: {
type: "global"
labels: {
project_id: "log-bench"
}
}
timestamp: "2021-02-02T23:03:31.190000057Z"
severity: "ERROR"
logName: "projects/log-bench/logs/bc230313-3f2b-4c0d-a4e2-5a91bb7fc98c_logging_winston_error_reporting_system_tests"
receiveTimestamp: "2021-02-02T23:03:31.581090452Z"
} Something in the changes is breaking error message formatting. Are you able to run tests locally yourself? You just need to set |
@nicoleczhu Sorry for the delay. I took a look at it today. I hadn't run the error test because I didn't have the error reporting API enabled so they naturally failed. Thankfully, after enabling them I was able to confirm the issue. It seems like an important use case and I'm glad the tests caught it. There doesn't appear to be an easy way to handle this case as error are formatted in very interesting ways... It seems that a formatter that is passed into a transport like The only way I can think of to handle this is:
and just allow for a json formatted logging to be the default, the error formatting will work. Unfortunately, in order to get the same display for errors, we would need a special catch case, which does not seem like it would be very robust. Otherwise, it seems like there isn't a great solution regardless and I can just close this PR. |
Hi @liboz , there doesn't seem to be a perfect solution here. Thank you for iterating on this though - now we know! Please feel free to close this PR for now. Thank you for your work here. |
Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:
Fixes #540, maybe (#536) 🦕
The formatted version of the message is stored in
info[MESSAGE]
notinfo.message
. This PR simply changes it to look at the correct location.