Skip to content

feat: Add option Parse.nodeLogging to fully log Parse.Object in Node.js environments #1594

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 6 commits into from
May 3, 2025

Conversation

dblythy
Copy link
Member

@dblythy dblythy commented Nov 3, 2022

New Pull Request Checklist

Issue Description

Currently, when logging a Parse.Object in NodeJS, the only thing that is logged is ParseObject { _objCount: 376, className: 'Person' }, which more often than not isn't overly helpful.

Related issue: n/a

Approach

Adds Parse.nodeLogging which logs the object out to:

ParseObject: className: Person, id: undefined
Attributes: {
  "foo": "bar"
}

TODOs before merging

  • Add tests

Summary by CodeRabbit

  • New Features
    • Introduced a static property to enable or disable enhanced logging for objects in Node.js environments.
    • When logging is enabled, objects provide detailed, formatted output showing class name, object ID, and attributes for easier debugging.
  • Tests
    • Added tests to verify the new logging property and the enhanced object output in Node.js.
  • Documentation
    • Updated type declarations to include the new logging property with usage warnings.

@parse-github-assistant
Copy link

parse-github-assistant bot commented Nov 3, 2022

🚀 Thanks for opening this pull request! We appreciate your effort in improving the project. Please let us know once your pull request is ready for review.

@mtrezza
Copy link
Member

mtrezza commented Nov 3, 2022

Does this influence existing built-in log messages? If so, maybe this should be optional, because logging object attributes may expose sensitive data in the logs.

@dblythy
Copy link
Member Author

dblythy commented Nov 3, 2022

Yes it does, that's why it defaults to false at the moment

@mtrezza
Copy link
Member

mtrezza commented Nov 3, 2022

Alright, maybe we can add a short warning note about that to the option JSdoc.

Copy link

codecov bot commented Apr 17, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (38a2e8a) to head (0540f7b).
Report is 1 commits behind head on alpha.

Additional details and impacted files
@@            Coverage Diff            @@
##             alpha     #1594   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           63        63           
  Lines         6167      6174    +7     
  Branches      1464      1465    +1     
=========================================
+ Hits          6167      6174    +7     

☔ 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.

@dplewis
Copy link
Member

dplewis commented Apr 17, 2025

Does this influence existing built-in log messages?

The symbols are scoped locally per object and doesn't influence existing built in logs

@mtrezza This is ready for review

@mtrezza
Copy link
Member

mtrezza commented Apr 19, 2025

I believe I was referring to when using the Parse SDK in Cloud Code, whether that will output additional logs to the requester, which may expose information about the object, for example in case of an error.

@dplewis
Copy link
Member

dplewis commented Apr 19, 2025

The requester will never see this right?

@mtrezza
Copy link
Member

mtrezza commented Apr 19, 2025

That depends on what the server sends to the requester in case of an error. I don't know whether there is currently an error handling anywhere in Parse Server that would cause the full object being returned to the requester.

In any case, I think my question back then was referring to the log files on the server side. Sensitive information should also not be in the log files by default. Maybe that's good for development, so if it's off by default that should be fine. I would just add an extra warning note to the option's doc that this should not be enabled in production. Maybe log a warning as well.

Copy link

coderabbitai bot commented May 3, 2025

📝 Walkthrough

"""

Walkthrough

A new configuration flag, NODE_LOGGING, was introduced to enable enhanced logging for Parse objects in Node.js environments. The flag is exposed as a static property, nodeLogging, on the Parse object, allowing users to enable or disable Node.js-specific logging behavior. When enabled, ParseObject instances receive a custom inspect method that outputs a formatted string representation for debugging. Corresponding tests and type declarations were updated to support and verify this new functionality.

Changes

File(s) Change Summary
src/CoreManager.ts Added NODE_LOGGING property to the config object with a default value of false.
src/Parse.ts Added static property accessor nodeLogging to the Parse object, delegating to CoreManager.
src/ParseObject.ts Updated ParseObject constructor to conditionally add a custom Node.js inspect method when NODE_LOGGING is enabled.
src/tests/Parse-test.js Added a test verifying the getter and setter behavior of Parse.nodeLogging.
src/tests/ParseObject-test.js Added a test verifying the custom inspect output of a ParseObject when logging is enabled.
types/Parse.d.ts Added static property nodeLogging with a boolean JSDoc annotation to the Parse type declaration.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant Parse
    participant CoreManager
    participant ParseObject

    User->>Parse: Set Parse.nodeLogging = true
    Parse->>CoreManager: Set NODE_LOGGING = true

    User->>ParseObject: new ParseObject(...)
    ParseObject->>CoreManager: Get NODE_LOGGING
    alt NODE_LOGGING is true
        ParseObject->>ParseObject: Attach custom inspect method
    end

    User->>ParseObject: Call inspect method (via util.inspect)
    ParseObject->>User: Return formatted string representation
Loading

"""


📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 48cc795 and 0540f7b.

📒 Files selected for processing (2)
  • src/Parse.ts (1 hunks)
  • types/Parse.d.ts (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
  • types/Parse.d.ts
  • src/Parse.ts
⏰ Context from checks skipped due to timeout of 90000ms (3)
  • GitHub Check: build (Node 20, 20.15.1)
  • GitHub Check: build (Node 22, 22.4.1)
  • GitHub Check: build (Node 18, 18.20.4)

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

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 (5)
src/__tests__/ParseObject-test.js (2)

3537-3544: Ensure NODE_LOGGING flag is always reset
The test manually sets NODE_LOGGING back to false at the end, but if the assertion fails, the flag remains true and may leak into subsequent tests. Consider using a shared teardown or a try/finally to guarantee cleanup. For example, add an afterEach hook at the top of this suite:

+describe('ParseObject pin', () => {
+  beforeEach(() => {
+    ParseObject.enableSingleInstance();
+    jest.clearAllMocks();
+    mockLocalDatastore.isEnabled = true;
+  });
+  afterEach(() => {
+    CoreManager.set('NODE_LOGGING', false);
+  });

3539-3542: Make the string comparison in the assertion more resilient
Using .toBe with a raw multi-line string is brittle—any minor formatting change will break the test. You could instead match on key parts or use a regex/snapshot:

// Example with regex:
expect(o[symbol]()).toMatch(
  /ParseObject: className: Person, id: undefined\s+Attributes:\s+\{\s+"foo": "bar"\s+\}/
);

Or leverage Jest snapshots:

expect(o[symbol]()).toMatchSnapshot();
src/ParseObject.ts (2)

189-195: Avoid per-instance function allocation
Allocating a new inspect function on every instance increases memory footprint. Consider defining the custom inspect method once on ParseObject.prototype when NODE_LOGGING is enabled, rather than inside the constructor.


189-195: Warn developers about sensitive data exposure
Enabling detailed logging can inadvertently expose PII or other sensitive attributes. It would be prudent to emit a console.warn when NODE_LOGGING is set to true, reminding users to avoid enabling this in production environments.

src/CoreManager.ts (1)

358-358: Document and type annotate the new NODE_LOGGING flag.

The new flag would benefit from an inline comment explaining its purpose, default, and caution for sensitive data. For example:

~// Enable detailed Node.js logging of Parse.Object instances. Off by default to avoid logging sensitive data.
~NODE_LOGGING: false,

Additionally, consider extending the Config interface with:

/** Enable detailed Node.js logging of Parse.Object instances */
NODE_LOGGING?: boolean;

so that the flag is explicitly typed in TypeScript.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 38a2e8a and 48cc795.

📒 Files selected for processing (6)
  • src/CoreManager.ts (1 hunks)
  • src/Parse.ts (1 hunks)
  • src/ParseObject.ts (1 hunks)
  • src/__tests__/Parse-test.js (1 hunks)
  • src/__tests__/ParseObject-test.js (1 hunks)
  • types/Parse.d.ts (1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
  • GitHub Check: build (Node 22, 22.4.1)
🔇 Additional comments (5)
src/CoreManager.ts (1)

358-358: Good implementation of the NODE_LOGGING flag with sensible default value

Setting the default value to false is a security-conscious choice that aligns with the PR objectives of avoiding unintentional exposure of sensitive data in logs.

types/Parse.d.ts (1)

325-329: LGTM - Property type definition properly documented

The type declaration and JSDoc are consistent with other similar properties in this file, making it clear that this is a boolean configuration flag.

src/Parse.ts (1)

317-326: LGTM - Well-implemented property accessor

The getter and setter implementation follows the established pattern in this codebase, properly delegating to CoreManager for the actual storage of the configuration value.

src/__tests__/Parse-test.js (1)

209-214: LGTM - Comprehensive test case

This test appropriately verifies the default state and the ability to toggle the setting, ensuring the feature can be enabled and disabled as needed.

src/ParseObject.ts (1)

189-195: Correct usage of util.inspect.custom symbol
The custom inspect method correctly leverages Symbol.for('nodejs.util.inspect.custom') to provide detailed output—including class name, ID, and a nicely formatted JSON of attributes—when NODE_LOGGING is enabled.

coderabbitai[bot]
coderabbitai bot previously approved these changes May 3, 2025
@mtrezza
Copy link
Member

mtrezza commented May 3, 2025

I've added a note to the JSDoc of set nodeLogging, if that's fine, I'll go ahead and merge.

@mtrezza mtrezza changed the title feat: Add Parse.nodeLogging to fully log Parse.Object feat: Add Parse.nodeLogging to fully log Parse.Object May 3, 2025
@mtrezza mtrezza changed the title feat: Add Parse.nodeLogging to fully log Parse.Object feat: Add option Parse.nodeLogging to fully log Parse.Object May 3, 2025
@mtrezza mtrezza changed the title feat: Add option Parse.nodeLogging to fully log Parse.Object feat: Add option Parse.nodeLogging to fully log Parse.Object in Node.js environments May 3, 2025
@dplewis
Copy link
Member

dplewis commented May 3, 2025

LGTM!

@parseplatformorg
Copy link
Contributor

parseplatformorg commented May 3, 2025

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

security/snyk check is complete. No issues have been found. (View Details)

@mtrezza mtrezza merged commit de9d057 into parse-community:alpha May 3, 2025
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants