Skip to content

Conversation

@mtrezza
Copy link
Member

@mtrezza mtrezza commented Nov 8, 2025

logClientEvents## Pull Request

Issue

When running Parse Server in production, understanding MongoDB client behavior is crucial for:

  • Monitoring connection health: Track topology changes, server state transitions, and connection pool events
  • Debugging connectivity issues: Identify network problems, DNS resolution issues, or replica set failovers
  • Performance optimization: Monitor connection pool usage and identify bottlenecks
  • Operational insights: Gain visibility into MongoDB driver behavior without modifying application code

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 logClientEvents option to DatabaseOptions that 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 logged
  • logLevel: Parse Server log level to use (error, warn, info, debug)

Usage Example

const server = new ParseServer({
  databaseURI: 'mongodb://localhost:27017/parse',
  databaseOptions: {
    logClientEvents: [
      {
        name: 'topologyDescriptionChanged',
        keys: ['previousDescription.type', 'newDescription.type', 'newDescription.servers.size'],
        logLevel: 'warn'
      },
      {
        name: 'serverDescriptionChanged',
        keys: ['address', 'previousDescription.type', 'newDescription.type'],
        logLevel: 'warn'
      },
      {
        name: 'connectionPoolCleared',
        keys: ['address', 'serviceId'],
        logLevel: 'error'
      },
      {
        name: 'connectionPoolReady',
        keys: ['address'],
        logLevel: 'info'
      }
    ]
  },
  // ... other options
});

Log Output Example

[warn] MongoDB client event topologyDescriptionChanged: {"previousDescription.type":"Unknown","newDescription.type":"ReplicaSetWithPrimary","newDescription.servers.size":3}
[error] MongoDB client event connectionPoolCleared: {"address":"localhost:27017","serviceId":"abc123"}
[info] MongoDB client event connectionPoolReady: {"address":"localhost:27017"}

Tasks

  • Add tests
  • Add changes to documentation (guides, repository pages, code comments)

Summary by CodeRabbit

  • New Features

    • Add configurable MongoDB client event logging: specify event names, log level, and optional dot-notated fields to extract; invalid levels fall back to info.
    • Safer payload logging with improved serialization for Map/Set, circular-reference protection (emits warning), and option to log full payload when no keys specified.
  • Documentation

    • Added options and docs for client event logging and available log levels.
  • Tests

    • Expanded tests for logging extraction, levels, serialization, and error handling.

@parse-github-assistant
Copy link

parse-github-assistant bot commented Nov 8, 2025

🚀 Thanks for opening this pull request!

@parseplatformorg
Copy link
Contributor

parseplatformorg commented Nov 8, 2025

Snyk checks have passed. No issues have been found so far.

Status Scanner Critical High Medium Low Total (0)
Open Source Security 0 0 0 0 0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

@coderabbitai
Copy link

coderabbitai bot commented Nov 8, 2025

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 @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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.

📥 Commits

Reviewing files that changed from the base of the PR and between 431af6a and c795b31.

📒 Files selected for processing (2)
  • resources/buildConfigDefinitions.js (1 hunks)
  • src/Options/Definitions.js (3 hunks)
📝 Walkthrough

Walkthrough

Adds 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

Cohort / File(s) Summary
MongoDB adapter + wiring
src/Adapters/Storage/Mongo/MongoStorageAdapter.js
Adds private _logClientEvents sourced from mongoOptions.logClientEvents, removes it from options passed to the driver, and registers per-event listeners on connect that select keys (dot-notation), resolve log level (fallback to info), safely serialize payloads (Map/Set/circular), and emit formatted log messages.
Option definitions & docs
src/Options/Definitions.js, src/Options/docs.js, src/Options/index.js
Introduces LogLevel and LogClientEvent interfaces and a new logClientEvents DatabaseOptions entry (PARSE_SERVER_DATABASE_LOG_CLIENT_EVENTS) to configure which MongoDB client events to log, with keys and level. Updates related docs/comments.
Circular replacer utility
src/Utils.js
Adds Utils.getCircularReplacer() returning a JSON.stringify replacer that converts Map to plain objects, Set to arrays, and replaces circular references with "[Circular]" using a WeakSet.
Tests — Mongo adapter
spec/MongoStorageAdapter.spec.js
Adds logClientEvents test suite covering: key extraction (dot notation), full payload logging when no keys, nested key extraction, invalid-level fallback, Map/Set serialization, missing keys handling, and circular payload handling (emits warning).
Tests — Utils
spec/Utils.spec.js
Adds tests for getCircularReplacer covering Map/Set serialization, direct and nested circular references, mixed structures, and non-circular objects.
Docs build style
jsdoc-conf.json
Minor CSS tweak for responsive logo rendering in generated docs.

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
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

  • Files to review closely:
    • src/Adapters/Storage/Mongo/MongoStorageAdapter.js — listener registration, dot-path key extraction, log level resolution, serialization and removal of option from driver options.
    • src/Utils.js — correctness and edge-case handling in getCircularReplacer (Map/Set conversion, circular detection).
    • src/Options/* and src/Options/docs.js — option parsing, typing and documentation consistency.
    • spec/MongoStorageAdapter.spec.js and spec/Utils.spec.js — validate test expectations (especially around circular handling and Map/Set serialization).

Possibly related PRs

  • parse-server#9897 — Modifies the same Mongo adapter area by changing which Parse-specific options are removed from driver options; likely related to option filtering and wiring.

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and specifically describes the main feature added: MongoDB client event logging via a new database option called logClientEvents.
Description check ✅ Passed The description follows the template structure, includes a detailed Issue section explaining the motivation, an Approach section describing the implementation with usage examples and log output, and marks both applicable tasks as complete.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@mtrezza mtrezza changed the title feat: Add support for MongoDB client events logging via database option clientLogEvents feat: Add support for MongoDB client event logging via database option clientLogEvents Nov 8, 2025
Copy link

@coderabbitai coderabbitai bot left a 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 clientLogEvents

Define 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 logLevel

Once 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 pattern

Definition is aligned with other array options. If you maintain types in generated output (like RateLimitOptions[]), consider emitting a type here via the generator for parity.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2424054 and 98c71c3.

📒 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 well

Description is clear and matches the intent.

@codecov
Copy link

codecov bot commented Nov 8, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.06%. Comparing base (cff451e) to head (c795b31).
⚠️ Report is 3 commits behind head on alpha.

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.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

coderabbitai[bot]
coderabbitai bot previously approved these changes Nov 8, 2025
@mtrezza mtrezza changed the title feat: Add support for MongoDB client event logging via database option clientLogEvents feat: Add MongoDB client event logging via database option clientLogEvents Nov 8, 2025
@mtrezza mtrezza changed the title feat: Add MongoDB client event logging via database option clientLogEvents feat: Add MongoDB client event logging via database option logClientEvents Nov 8, 2025
Copy link

@coderabbitai coderabbitai bot left a 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 since Array.isArray already returns false for null or undefined.

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

📥 Commits

Reviewing files that changed from the base of the PR and between f50da13 and fdfefd7.

📒 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 LogClientEvent type 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 logClientEvents property is correctly typed and positioned within DatabaseOptions.

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 _logClientEvents field is properly declared, initialized from configuration, and correctly excluded from options passed to the MongoDB client.

Also applies to: 158-158, 167-167

coderabbitai[bot]
coderabbitai bot previously approved these changes Nov 8, 2025
coderabbitai[bot]
coderabbitai bot previously approved these changes Nov 8, 2025
@mtrezza
Copy link
Member Author

mtrezza commented Nov 8, 2025

@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 ./src/Options/docs.js and ./src/Options/Definitions.js.

@coderabbitai
Copy link

coderabbitai bot commented Nov 8, 2025

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 logClientEvents option has been properly documented:

Required documentation (all present):

  • src/Options/index.js - Added LogClientEvent type and logClientEvents property to DatabaseOptions
  • src/Options/docs.js - Reflects the new logClientEvents property
  • src/Options/Definitions.js - Contains the option definition with env var and help text

Bonus documentation:

  • README.md - Includes a dedicated "MongoDB Client Event Logging" section with usage examples

The npm run definitions command appears to have been executed correctly, as both docs.js and Definitions.js contain the synchronized updates.


✏️ Learnings added
Learnt from: mtrezza
URL: https://github.com/parse-community/parse-server/pull/9914

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.

Learnt from: mtrezza
URL: https://github.com/parse-community/parse-server/pull/9914

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.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.


🧠 Learnings used
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.

Learnt from: mtrezza
Repo: parse-community/parse-server PR: 9445
File: spec/ParseLiveQuery.spec.js:1312-1338
Timestamp: 2025-05-04T20:41:05.147Z
Learning: New tests in the parse-server repository should use async/await with promise-based patterns rather than callback patterns with `done()`.

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: New tests in the parse-server repository should use async/await with promise-based patterns rather than callback patterns with `done()`. The preferred pattern is to create a Promise that resolves when an expected event occurs, then await that Promise.

Learnt from: EmpiDev
Repo: parse-community/parse-server PR: 9770
File: src/triggers.js:446-454
Timestamp: 2025-08-27T09:08:34.252Z
Learning: When analyzing function signature changes in Parse Server codebase, verify that call sites are actually incorrect before flagging them. Passing tests are a strong indicator that function calls are already properly aligned with new signatures.

Learnt from: EmpiDev
Repo: parse-community/parse-server PR: 9770
File: spec/CloudCode.spec.js:446-469
Timestamp: 2025-08-26T14:06:31.853Z
Learning: In the Parse Server codebase, when handling query objects in maybeRunAfterFindTrigger, objects without a where property that contain options like limit/skip should be treated as query JSON with an empty where clause using the spread pattern { where: {}, ...query }, not nested as { where: query }.

Copy link

@coderabbitai coderabbitai bot left a 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

📥 Commits

Reviewing files that changed from the base of the PR and between 0dec358 and 4c1039d.

📒 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.js
  • src/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 logClientEvents option is properly defined with the correct environment variable name, help text, and array parser.

src/Options/index.js (2)

611-618: LGTM!

The LogClientEvent interface 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 logClientEvents option is properly added to DatabaseOptions with correct Flow typing and clear documentation.

Copy link

@coderabbitai coderabbitai bot left a 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 logLevel as 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 ?string type 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

📥 Commits

Reviewing files that changed from the base of the PR and between 4c1039d and 0576cb2.

📒 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.js
  • src/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 logClientEvents property 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 // @flow directive at line 1).


754-755: LGTM! Property correctly added to DatabaseOptions.

The logClientEvents property 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.

@mtrezza mtrezza merged commit b760733 into parse-community:alpha Nov 8, 2025
25 of 27 checks passed
parseplatformorg pushed a commit that referenced this pull request Nov 8, 2025
# [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))
@parseplatformorg
Copy link
Contributor

🎉 This change has been released in version 8.5.0-alpha.4

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

Labels

state:released-alpha Released as alpha version

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants