Skip to content
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

feat: Allow configuring pino to log with different keys #1867

Merged
merged 10 commits into from
Jan 7, 2024

Conversation

drewcorlin1
Copy link
Contributor

Which problem is this PR solving?

#1664

Short description of the changes

Allow configuring the keys that the pino instrumentation adds to logs

@drewcorlin1 drewcorlin1 requested a review from a team December 17, 2023 20:58
}

before(() => {
setup();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand this correct this causes that all tests below use the new keys, not just the new injects span context to records with custom keys test.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's right. I was having trouble configuring just one test independently of the others with the current setup. I can spend a bit more time on it

Copy link
Contributor Author

@drewcorlin1 drewcorlin1 Dec 18, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cleaned them up so that the logKeys config only applies to a single test but the tests are interfering with each other causing the "disabled instrumentation" block of tests to fail. If I comment out all the other describe blocks then they pass. I'm stumped at the moment but will revisit this in the next couple days

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like the pino tests were written in a way to instrument just once and then run all tests.
Don't know if there was a reason. Theoretically .disable() should cause to de-instrument and therefore should allow side effect free tests.
But there might be cases where de-instrument doesn't work, e.g. if pino caches some stuff internal.

Copy link
Contributor Author

@drewcorlin1 drewcorlin1 Dec 18, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I definitely don't have a perfect understanding of this patching, but I tried creating a new instrumentation + explicitly calling enable() on it as well as clearing the require cache via delete require.cache[require.resolve('pino')] but it made no difference. Would love to hear alternatives to try as welll

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I broke the enabled + disabled tests out into their own modules to skirt the problem. Let me know what you think

Copy link

codecov bot commented Dec 17, 2023

Codecov Report

Merging #1867 (b179e33) into main (bb1ba31) will increase coverage by 0.00%.
The diff coverage is 100.00%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #1867   +/-   ##
=======================================
  Coverage   91.45%   91.45%           
=======================================
  Files         145      145           
  Lines        7410     7412    +2     
  Branches     1483     1484    +1     
=======================================
+ Hits         6777     6779    +2     
  Misses        633      633           
Files Coverage Δ
...emetry-instrumentation-pino/src/instrumentation.ts 96.00% <100.00%> (+0.10%) ⬆️

@Flarna
Copy link
Member

Flarna commented Dec 18, 2023

@seemk Could you as owner please take a look?

return record;
}

export function init(importType: 'global' | 'default' | 'pino' = 'global') {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps instead of using global this should return something like a test context object containing the currently global fields?

Copy link
Contributor

@seemk seemk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, just a subjective comment regarding globals.

@drewcorlin1
Copy link
Contributor Author

@seemk @Flarna could you run/approve the required workflows?

@drewcorlin1
Copy link
Contributor Author

Thank you @blumamir!

Could someone with access merge this whenever you get a chance, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants