Skip to content

Inherit methodFactory extensions from the parent to the child loggers. #4809

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

Merged
merged 8 commits into from
Apr 22, 2025

Conversation

toger5
Copy link
Contributor

@toger5 toger5 commented Apr 16, 2025

This fixes an issue where a log extension (a modification to the methodFactory) applied to a parent logger would ONLY be executed when logging with the parent but not on any of the children created with getChild().

This PR changes getChild to also inherit the methodFactory from the parent.

Checklist

  • Tests written for new code (and old code if feasible).
  • New or updated public/exported symbols have accurate TSDoc documentation.
  • Linter and other CI checks pass.
  • Sign-off given on the changes (see CONTRIBUTING.md).

@toger5 toger5 changed the title use methodFactory extensions from the rootLogger in child loggers. Inherit methodFactory extensions from the parent to the child loggers. Apr 17, 2025
@toger5 toger5 marked this pull request as ready for review April 17, 2025 11:12
@toger5 toger5 requested a review from a team as a code owner April 17, 2025 11:12
@toger5 toger5 requested review from dbkr and florianduros April 17, 2025 11:12
Copy link
Member

@dbkr dbkr left a comment

Choose a reason for hiding this comment

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

Ummm... I think I understand the PR you referenced but I'm afraid I don't understand what's going on here, and the amount of casting through unknown and splicing of methods to other objects is terrifying. If we do this, it needs very heavy commenting!

@toger5
Copy link
Contributor Author

toger5 commented Apr 17, 2025

@dbkr I found that rebuild is doing the same thing as childLogger.setLevel(childLogger.getLevel());
Additionally it was possible to make the types a lot more easy to follow by returning PrefixedLogger from getPrefixedLogger and then chinging the type once we export logger export const logger = getPrefixedLogger() as LoggerWithLogMethod;

@toger5 toger5 requested a review from dbkr April 17, 2025 18:32
@toger5 toger5 requested a review from robintown April 19, 2025 12:30
Copy link
Member

@dbkr dbkr left a comment

Choose a reason for hiding this comment

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

OK - thanks for the comments, I think it's a bit easier to see what's happening now.

@toger5 toger5 removed the request for review from florianduros April 22, 2025 10:51
Copy link
Member

@BillCarsonFr BillCarsonFr left a comment

Choose a reason for hiding this comment

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

ok

@toger5 toger5 added this pull request to the merge queue Apr 22, 2025
@richvdh
Copy link
Member

richvdh commented Apr 22, 2025

This is an experiment where I tried to get the same thing I am doing in: #4807

I assume it is no longer an experiment? Could you update the PR description to reflect the current state, please?

Copy link
Member

@richvdh richvdh left a comment

Choose a reason for hiding this comment

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

looks generally good, a few clarifications though please

@florianduros
Copy link
Contributor

florianduros commented Apr 22, 2025

@toger5 the PR breaks the https://github.com/matrix-org/complement-crypto tests. These tests are run when the PR is put in the merge queue.

@toger5
Copy link
Contributor Author

toger5 commented Apr 22, 2025

@florianduros any idea how it breaks it?
Do we rely on logging output for the tests?

@florianduros
Copy link
Contributor

florianduros commented Apr 22, 2025

@toger5 Complement crypto runs the tests with an older version of loglevel (https://github.com/matrix-org/complement-crypto/blob/main/internal/api/js/js-sdk/yarn.lock#L226 1.8.1). rebuild method was added pimterry/loglevel#189 in January in the 1.9.0

@toger5
Copy link
Contributor Author

toger5 commented Apr 22, 2025

@florianduros I think it makes sense to not use the rebuild method in that case especailly since we do have a workaround.

@toger5 toger5 force-pushed the toger5/try-getting-logger-getChild-to-work branch from 20e178d to 8e83e09 Compare April 22, 2025 14:49
src/logger.ts Outdated
childLogger.rebuild();
// childLogger.rebuild();
// TODO: As a stop-gap we use the deprecated method of rebuilding the logger
// by setting the level. Complement Crypto uses an older version of loglevel.
Copy link
Contributor

@florianduros florianduros Apr 22, 2025

Choose a reason for hiding this comment

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

Should we instead update the dependency in complement crypto?

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 have done this in: matrix-org/complement-crypto#173

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks!

toger5 added a commit to matrix-org/complement-crypto that referenced this pull request Apr 22, 2025
@toger5 toger5 force-pushed the toger5/try-getting-logger-getChild-to-work branch from 8e83e09 to 54ecd1f Compare April 22, 2025 15:11
@toger5
Copy link
Contributor Author

toger5 commented Apr 22, 2025

I reverted the last commit and we fix the issue with the updated complement-crypto PR.

@@ -56,7 +56,7 @@
"bs58": "^6.0.0",
"content-type": "^1.0.4",
"jwt-decode": "^4.0.0",
"loglevel": "^1.7.1",
"loglevel": "^1.9.2",
Copy link
Member

Choose a reason for hiding this comment

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

FTR, I think this could equally be ^1.9.0, since that's where .rebuild was introduced, but I don't imagine it makes much difference in practice.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It does not hurt to include the minor patches.

Copy link
Member

@richvdh richvdh Apr 22, 2025

Choose a reason for hiding this comment

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

It does not hurt to include the minor patches.

In this specific situation, I agree, but in general, that's not correct.

The reason it might hurt is that a downstream application may have specifically decided that they want to use 1.9.0 or 1.9.1, for some reason and pinned their dependencies accordingly. (For example, maybe it turns out that 1.9.2 introduces a regression in their application). There is no need for matrix-js-sdk to insist on 1.9.2, and as a general principle package.json should list the earliest versions that we are compatible with.

Nevertheless that seems an unlikely scenario here. So I'm not going to insist you change it. But bear in mind for future :).

Copy link
Member

@richvdh richvdh left a comment

Choose a reason for hiding this comment

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

LGTM

@toger5 toger5 added this pull request to the merge queue Apr 22, 2025
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Apr 22, 2025
@toger5 toger5 added this pull request to the merge queue Apr 22, 2025
Merged via the queue into develop with commit 19b1b90 Apr 22, 2025
30 checks passed
@toger5 toger5 deleted the toger5/try-getting-logger-getChild-to-work branch April 22, 2025 16:41
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.

6 participants