-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
feat: Add MongoDB client event logging via database option logClientEvents
#9914
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
Conversation
|
🚀 Thanks for opening this pull request! |
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
|
Warning Rate limit exceeded@mtrezza has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 4 minutes and 18 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughAdds configurable MongoDB client event logging (key selection, level, safe serialization) and a circular-safe JSON replacer utility, plus tests covering event logging behaviors and serialization edge cases. Changes
Sequence Diagram(s)sequenceDiagram
participant App as Application
participant MA as MongoStorageAdapter
participant Mongo as MongoClient
participant Logger as Logger
App->>MA: connect(mongoOptions with logClientEvents)
activate MA
MA->>MA: set _logClientEvents from mongoOptions
MA->>Mongo: create/connect client
alt _logClientEvents configured
MA->>Mongo: register listener for each event name
end
deactivate MA
Note over Mongo: Event emitted (e.g., serverDescriptionChanged)
Mongo->>MA: call registered listener
activate MA
MA->>MA: build logData (selected keys or full payload)
MA->>MA: determine logLevel (fallback to info)
MA->>MA: serialize via getCircularReplacer (Map/Set/circular-safe)
MA->>Logger: log "MongoDB client event <name>: <data>" at computed level
deactivate MA
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Possibly related PRs
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
clientLogEventsclientLogEvents
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.
Actionable comments posted: 1
🧹 Nitpick comments (3)
src/Options/index.js (1)
728-729: Stronger typing for clientLogEventsDefine a Flow type for the event config and use it here for clarity and tooling.
Apply:
@@ type RequestKeywordDenylist = { key: string | any, value: any, }; + +// MongoDB client event logging config +export type ClientLogEvent = { + name: string, + keys?: string[], + logLevel?: 'error' | 'warn' | 'info' | 'debug', +}; @@ /* An array of MongoDB client event configurations to enable logging of specific events. Each configuration object should contain:<br><ul><li>`name` (the event name, e.g., 'topologyDescriptionChanged', 'serverDescriptionChanged', 'connectionPoolCleared', 'connectionPoolReady')</li><li>`keys` (optional array of dot-notation paths to extract specific data from the event object; if not provided or empty, the entire event object will be logged)</li><li>`logLevel` (the log level to use for this event: 'error', 'warn', 'info', 'debug', etc.).</li></ul> */ - clientLogEvents: ?(any[]); + clientLogEvents: ?(ClientLogEvent[]);spec/MongoStorageAdapter.spec.js (1)
828-934: Add a negative test for invalid logLevelOnce the adapter guards unknown levels, add a test asserting it falls back to
info(or chosen default) instead of throwing. Keeps behavior resilient to misconfig.src/Options/Definitions.js (1)
1120-1125: LGTM; consistent with existing patternDefinition is aligned with other array options. If you maintain types in generated output (like
RateLimitOptions[]), consider emitting atypehere via the generator for parity.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
spec/MongoStorageAdapter.spec.js(1 hunks)src/Adapters/Storage/Mongo/MongoStorageAdapter.js(4 hunks)src/Options/Definitions.js(1 hunks)src/Options/docs.js(1 hunks)src/Options/index.js(1 hunks)
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-10-16T19:27:05.311Z
Learnt from: Moumouls
Repo: parse-community/parse-server PR: 9883
File: spec/CloudCodeLogger.spec.js:410-412
Timestamp: 2025-10-16T19:27:05.311Z
Learning: In spec/CloudCodeLogger.spec.js, the test "should log cloud function triggers using the silent log level" (around lines 383-420) is known to be flaky and requires the extra `await new Promise(resolve => setTimeout(resolve, 100))` timeout after awaiting `afterSavePromise` for reliability, even though it may appear redundant.
Applied to files:
spec/MongoStorageAdapter.spec.js
📚 Learning: 2025-05-09T09:59:06.289Z
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 9445
File: spec/ParseLiveQuery.spec.js:1340-1375
Timestamp: 2025-05-09T09:59:06.289Z
Learning: Tests in the parse-server repository should use promise-based approaches rather than callback patterns with `done()`. Use a pattern where a Promise is created that resolves when the event occurs, then await that promise.
Applied to files:
spec/MongoStorageAdapter.spec.js
🧬 Code graph analysis (3)
spec/MongoStorageAdapter.spec.js (3)
src/Adapters/Storage/Postgres/PostgresStorageAdapter.js (1)
logger(19-19)spec/ParseLiveQuery.spec.js (3)
logger(299-299)logger(589-589)logger(632-632)spec/helper.js (5)
require(6-6)require(8-8)require(61-61)MongoStorageAdapter(58-58)databaseURI(66-66)
src/Options/Definitions.js (1)
resources/buildConfigDefinitions.js (1)
parsers(12-12)
src/Adapters/Storage/Mongo/MongoStorageAdapter.js (1)
src/Adapters/Storage/Postgres/PostgresStorageAdapter.js (1)
logger(19-19)
🪛 Biome (2.1.2)
src/Options/index.js
[error] 728-728: Expected a statement but instead found '?'.
Expected a statement here.
(parse)
src/Adapters/Storage/Mongo/MongoStorageAdapter.js
[error] 135-135: return types can only be used in TypeScript files
remove this type annotation
(parse)
[error] 135-135: expected a semicolon to end the class property, but found none
(parse)
[error] 135-135: Expected an identifier, a string literal, a number literal, a private field name, or a computed name but instead found '?'.
Expected an identifier, a string literal, a number literal, a private field name, or a computed name here.
(parse)
[error] 135-135: type parameters are a TypeScript only feature. Convert your file to a TypeScript file or remove the syntax.
TypeScript only syntax
(parse)
[error] 135-135: Expected a class parameters but instead found ';'.
Expected a class parameters here.
(parse)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (13)
- GitHub Check: Node 18
- GitHub Check: MongoDB 7, ReplicaSet
- GitHub Check: Redis Cache
- GitHub Check: Node 20
- GitHub Check: Node 22
- GitHub Check: MongoDB 8, ReplicaSet
- GitHub Check: PostgreSQL 17, PostGIS 3.5
- GitHub Check: MongoDB 6, ReplicaSet
- GitHub Check: PostgreSQL 15, PostGIS 3.5
- GitHub Check: PostgreSQL 18, PostGIS 3.6
- GitHub Check: PostgreSQL 16, PostGIS 3.5
- GitHub Check: PostgreSQL 15, PostGIS 3.3
- GitHub Check: PostgreSQL 15, PostGIS 3.4
🔇 Additional comments (2)
src/Options/index.js (1)
1-1: Biome parse error is a false positive (Flow syntax)This file uses Flow types (e.g.,
?T), which Biome flagged. Either configure Biome to understand Flow or exclude Flow-typed sources to avoid noise.src/Options/docs.js (1)
249-249: Docs addition reads wellDescription is clear and matches the intent.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## alpha #9914 +/- ##
==========================================
- Coverage 93.06% 93.06% -0.01%
==========================================
Files 187 187
Lines 15187 15213 +26
Branches 177 177
==========================================
+ Hits 14134 14158 +24
- Misses 1041 1043 +2
Partials 12 12 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
clientLogEventsclientLogEvents
clientLogEventslogClientEvents
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.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/Adapters/Storage/Mongo/MongoStorageAdapter.js (1)
211-211: Simplify the array check.The condition
this._logClientEvents && Array.isArray(this._logClientEvents)is redundant sinceArray.isArrayalready returnsfalsefornullorundefined.Apply this diff:
- if (this._logClientEvents && Array.isArray(this._logClientEvents)) { + if (Array.isArray(this._logClientEvents)) {
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
spec/MongoStorageAdapter.spec.js(1 hunks)src/Adapters/Storage/Mongo/MongoStorageAdapter.js(5 hunks)src/Options/Definitions.js(1 hunks)src/Options/docs.js(1 hunks)src/Options/index.js(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- spec/MongoStorageAdapter.spec.js
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-10-16T19:27:05.311Z
Learnt from: Moumouls
Repo: parse-community/parse-server PR: 9883
File: spec/CloudCodeLogger.spec.js:410-412
Timestamp: 2025-10-16T19:27:05.311Z
Learning: In spec/CloudCodeLogger.spec.js, the test "should log cloud function triggers using the silent log level" (around lines 383-420) is known to be flaky and requires the extra `await new Promise(resolve => setTimeout(resolve, 100))` timeout after awaiting `afterSavePromise` for reliability, even though it may appear redundant.
Applied to files:
src/Adapters/Storage/Mongo/MongoStorageAdapter.js
📚 Learning: 2025-04-30T19:31:35.344Z
Learnt from: RahulLanjewar93
Repo: parse-community/parse-server PR: 9744
File: spec/ParseLiveQuery.spec.js:0-0
Timestamp: 2025-04-30T19:31:35.344Z
Learning: In the Parse Server codebase, the functions in QueryTools.js are typically tested through end-to-end behavior tests rather than direct unit tests, even though the functions are exported from the module.
Applied to files:
src/Adapters/Storage/Mongo/MongoStorageAdapter.js
🧬 Code graph analysis (2)
src/Options/Definitions.js (1)
resources/buildConfigDefinitions.js (1)
parsers(12-12)
src/Adapters/Storage/Mongo/MongoStorageAdapter.js (2)
src/Adapters/Storage/Postgres/PostgresStorageAdapter.js (1)
logger(19-19)src/Adapters/Logger/WinstonLogger.js (1)
logger(8-8)
🪛 Biome (2.1.2)
src/Options/index.js
[error] 611-611: Expected a statement but instead found '?'.
Expected a statement here.
(parse)
[error] 611-611: Expected a statement but instead found '}'.
Expected a statement here.
(parse)
[error] 737-737: Expected a statement but instead found '?'.
Expected a statement here.
(parse)
src/Adapters/Storage/Mongo/MongoStorageAdapter.js
[error] 3-3: 'import type' are a TypeScript only feature. Convert your file to a TypeScript file or remove the syntax.
TypeScript only syntax
(parse)
[error] 135-135: return types can only be used in TypeScript files
remove this type annotation
(parse)
[error] 135-135: expected a semicolon to end the class property, but found none
(parse)
[error] 135-135: Expected an identifier, a string literal, a number literal, a private field name, or a computed name but instead found '?'.
Expected an identifier, a string literal, a number literal, a private field name, or a computed name here.
(parse)
[error] 135-135: type parameters are a TypeScript only feature. Convert your file to a TypeScript file or remove the syntax.
TypeScript only syntax
(parse)
[error] 135-135: Expected a class parameters but instead found ';'.
Expected a class parameters here.
(parse)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (14)
- GitHub Check: PostgreSQL 17, PostGIS 3.5
- GitHub Check: PostgreSQL 15, PostGIS 3.5
- GitHub Check: Node 18
- GitHub Check: PostgreSQL 16, PostGIS 3.5
- GitHub Check: PostgreSQL 18, PostGIS 3.6
- GitHub Check: PostgreSQL 15, PostGIS 3.4
- GitHub Check: Node 22
- GitHub Check: Node 20
- GitHub Check: MongoDB 8, ReplicaSet
- GitHub Check: PostgreSQL 15, PostGIS 3.3
- GitHub Check: MongoDB 7, ReplicaSet
- GitHub Check: Redis Cache
- GitHub Check: MongoDB 6, ReplicaSet
- GitHub Check: Docker Build
🔇 Additional comments (5)
src/Options/index.js (2)
611-618: LGTM! Well-designed type for event logging configuration.The
LogClientEventtype appropriately models the configuration needs: event name, optional selective key extraction, and log level specification.
737-738: LGTM! Property declaration is consistent with the feature design.The
logClientEventsproperty is correctly typed and positioned withinDatabaseOptions.src/Options/docs.js (1)
265-265: LGTM! Comprehensive and helpful documentation.The JSDoc clearly explains the configuration structure with practical examples of MongoDB event names and clarifies the optional keys field behavior.
src/Options/Definitions.js (1)
1222-1227: LGTM! Configuration definition follows established patterns.The option is properly wired with appropriate environment variable, parser, and help text that matches the JSDoc documentation.
src/Adapters/Storage/Mongo/MongoStorageAdapter.js (1)
135-135: LGTM! Field declaration and initialization follow established patterns.The
_logClientEventsfield is properly declared, initialized from configuration, and correctly excluded from options passed to the MongoDB client.Also applies to: 158-158, 167-167
|
@coderabbitai, always check whether a new feature is documented in the README.md file. For a new Parse Server option it's sufficient to be documented in the options definitions (./src/Options/index.js) and ensure npm run definitions has been executed so the changes are reflected in |
|
Tip For best results, initiate chat on the files or code changes. @mtrezza, thank you for the guidance! I've noted this for future reviews. For this PR, I can confirm that the new ✅ Required documentation (all present):
✅ Bonus documentation:
The ✏️ Learnings added
🧠 Learnings used |
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.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
src/Options/Definitions.js(2 hunks)src/Options/docs.js(2 hunks)src/Options/index.js(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/Options/docs.js
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.917Z
Learning: When reviewing Parse Server PRs that add new features, always check whether the feature is documented in the README.md file, though for new Parse Server options this is optional rather than required.
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.917Z
Learning: For new Parse Server options, verify that the option is documented in src/Options/index.js and that npm run definitions has been executed to reflect changes in src/Options/docs.js and src/Options/Definitions.js. README.md documentation is a bonus but not required for new options.
📚 Learning: 2025-11-08T13:46:04.917Z
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.917Z
Learning: For new Parse Server options, verify that the option is documented in src/Options/index.js and that npm run definitions has been executed to reflect changes in src/Options/docs.js and src/Options/Definitions.js. README.md documentation is a bonus but not required for new options.
Applied to files:
src/Options/Definitions.jssrc/Options/index.js
🧬 Code graph analysis (1)
src/Options/Definitions.js (1)
resources/buildConfigDefinitions.js (1)
parsers(12-12)
🪛 Biome (2.1.2)
src/Options/index.js
[error] 611-611: Expected a statement but instead found '?'.
Expected a statement here.
(parse)
[error] 611-611: Expected a statement but instead found '}'.
Expected a statement here.
(parse)
[error] 616-616: Expected a type but instead found '?'.
Expected a type here.
(parse)
[error] 616-616: Expected a property, or a signature but instead found ';'.
Expected a property, or a signature here.
(parse)
[error] 737-737: Expected a statement but instead found '?'.
Expected a statement here.
(parse)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (14)
- GitHub Check: Node 22
- GitHub Check: Redis Cache
- GitHub Check: Node 18
- GitHub Check: Node 20
- GitHub Check: MongoDB 6, ReplicaSet
- GitHub Check: MongoDB 8, ReplicaSet
- GitHub Check: MongoDB 7, ReplicaSet
- GitHub Check: PostgreSQL 17, PostGIS 3.5
- GitHub Check: PostgreSQL 15, PostGIS 3.3
- GitHub Check: PostgreSQL 15, PostGIS 3.5
- GitHub Check: PostgreSQL 15, PostGIS 3.4
- GitHub Check: PostgreSQL 18, PostGIS 3.6
- GitHub Check: PostgreSQL 16, PostGIS 3.5
- GitHub Check: Docker Build
🔇 Additional comments (3)
src/Options/Definitions.js (1)
1241-1245: LGTM!The
logClientEventsoption is properly defined with the correct environment variable name, help text, and array parser.src/Options/index.js (2)
611-618: LGTM!The
LogClientEventinterface is well-defined with clear documentation and proper Flow type annotations. The static analysis errors reported by Biome are false positives—Flow's optional type syntax (?Type) is valid here.
737-738: LGTM!The
logClientEventsoption is properly added toDatabaseOptionswith correct Flow typing and clear documentation.
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.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/Options/index.js (1)
627-635: LGTM! LogClientEvent interface is well-defined.The interface clearly defines the MongoDB client event configuration structure with helpful documentation and links to MongoDB driver docs.
For stricter type safety, consider typing
logLevelas a union of the valid log level strings:/* The log level to use for this event. See [LogLevel](LogLevel.html) for available values. Defaults to `'info'`. :DEFAULT: info */ - logLevel: ?string; + logLevel: ?('error' | 'warn' | 'info' | 'verbose' | 'debug' | 'silly');However, the current
?stringtype is consistent with other log level fields in this file (e.g., line 97), so this change is optional.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
src/Options/Definitions.js(3 hunks)src/Options/docs.js(3 hunks)src/Options/index.js(3 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/Options/Definitions.js
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.917Z
Learning: When reviewing Parse Server PRs that add new features, always check whether the feature is documented in the README.md file, though for new Parse Server options this is optional rather than required.
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.917Z
Learning: For new Parse Server options, verify that the option is documented in src/Options/index.js and that npm run definitions has been executed to reflect changes in src/Options/docs.js and src/Options/Definitions.js. README.md documentation is a bonus but not required for new options.
📚 Learning: 2025-11-08T13:46:04.917Z
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.917Z
Learning: For new Parse Server options, verify that the option is documented in src/Options/index.js and that npm run definitions has been executed to reflect changes in src/Options/docs.js and src/Options/Definitions.js. README.md documentation is a bonus but not required for new options.
Applied to files:
src/Options/docs.jssrc/Options/index.js
📚 Learning: 2025-10-16T19:27:05.311Z
Learnt from: Moumouls
Repo: parse-community/parse-server PR: 9883
File: spec/CloudCodeLogger.spec.js:410-412
Timestamp: 2025-10-16T19:27:05.311Z
Learning: In spec/CloudCodeLogger.spec.js, the test "should log cloud function triggers using the silent log level" (around lines 383-420) is known to be flaky and requires the extra `await new Promise(resolve => setTimeout(resolve, 100))` timeout after awaiting `afterSavePromise` for reliability, even though it may appear redundant.
Applied to files:
src/Options/index.js
🧬 Code graph analysis (1)
src/Options/index.js (1)
src/Controllers/LoggerController.js (2)
LogLevel(9-12)LogLevel(9-12)
🪛 Biome (2.1.2)
src/Options/index.js
[error] 611-611: Expected a statement but instead found '?'.
Expected a statement here.
(parse)
[error] 611-611: Expected a statement but instead found '}'.
Expected a statement here.
(parse)
[error] 632-632: Expected a type but instead found '?'.
Expected a type here.
(parse)
[error] 632-632: Expected a property, or a signature but instead found ';'.
Expected a property, or a signature here.
(parse)
[error] 754-754: Expected a statement but instead found '?'.
Expected a statement here.
(parse)
[error] 767-767: Expected a type but instead found '?'.
Expected a type here.
(parse)
[error] 767-767: Expected a property, or a signature but instead found ';'.
Expected a property, or a signature here.
(parse)
[error] 767-767: Expected a statement but instead found '}'.
Expected a statement here.
(parse)
[error] 771-771: Expected a type but instead found '?'.
Expected a type here.
(parse)
[error] 771-771: Expected a property, or a signature but instead found ';'.
Expected a property, or a signature here.
(parse)
[error] 775-775: Expected a statement but instead found '?'.
Expected a statement here.
(parse)
[error] 779-779: Expected a statement but instead found '?'.
Expected a statement here.
(parse)
[error] 783-783: Expected a statement but instead found '?'.
Expected a statement here.
(parse)
🔇 Additional comments (7)
src/Options/docs.js (4)
241-249: LGTM! LogLevel interface is well-documented.The interface clearly defines all six standard log levels with appropriate descriptions and priorities.
252-256: LGTM! LogClientEvent interface is properly documented.The interface clearly documents the MongoDB client event configuration with helpful external references and default values.
282-282: LGTM! Property addition is consistent with interface.The
logClientEventsproperty is properly typed and documented.
324-328: LGTM! Documentation cross-references improve clarity.The added references to LogLevel.html help users understand available log level values.
src/Options/index.js (3)
611-625: LGTM! LogLevel interface correctly defines standard log levels.The interface properly defines all six standard log levels using Flow string literal types. The static analysis errors from Biome are false positives—Biome doesn't correctly parse Flow syntax (note the
// @flowdirective at line 1).
754-755: LGTM! Property correctly added to DatabaseOptions.The
logClientEventsproperty is properly typed and documented, following the established patterns in this interface.
767-786: LGTM! Documentation improvements enhance clarity.The added references to LogLevel.html help users understand which values are valid for each log level property.
# [8.5.0-alpha.4](8.5.0-alpha.3...8.5.0-alpha.4) (2025-11-08) ### Features * Add MongoDB client event logging via database option `logClientEvents` ([#9914](#9914)) ([b760733](b760733))
|
🎉 This change has been released in version 8.5.0-alpha.4 |
logClientEvents## Pull Request
Issue
When running Parse Server in production, understanding MongoDB client behavior is crucial for:
Previously, developers had limited visibility into MongoDB driver events unless they manually instrumented the code or enabled MongoDB driver debugging (which produces excessive output).
Approach
This feature adds a new
logClientEventsoption toDatabaseOptionsthat accepts an array of event configurations. Each configuration specifies:name: The MongoDB driver event to listen for (e.g.,topologyDescriptionChanged,serverDescriptionChanged,connectionPoolCleared,connectionPoolReady)keys(optional): Dot-notation paths to extract specific fields from the event object. If omitted, the entire event is loggedlogLevel: Parse Server log level to use (error,warn,info,debug)Usage Example
Log Output Example
Tasks
Summary by CodeRabbit
New Features
Documentation
Tests