feat: Add option to change log levels of username already exists message #9962
Conversation
|
🚀 Thanks for opening this pull request! |
📝 WalkthroughWalkthroughAdds a new log-level option Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20–30 minutes
Pre-merge checks and finishing touches❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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 |
✅ 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. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## alpha #9962 +/- ##
=======================================
Coverage 92.58% 92.58%
=======================================
Files 191 191
Lines 15544 15549 +5
Branches 177 177
=======================================
+ Hits 14391 14396 +5
Misses 1141 1141
Partials 12 12 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
I think we can also the default level for this to |
Do you mean this object ? This is because in the issue you mentionned this kind of object: Do you want I delete the object and pass directly the option ? |
|
I see where you got this from. May have been a typo. logLevels: {
env: 'PARSE_SERVER_LOG_LEVELS',
help: '(Optional) Overrides the log levels used internally by Parse Server to log events.',
action: parsers.objectParser,
type: 'LogLevels',
default: {},
},Let's add there, unless you can think of a reason not to? They are grouped by prefix, |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
types/Options/index.d.ts (1)
1-126: PR title suggestion in Angular conventionTo align with the repo’s preferred Angular-style convention, consider updating the PR title to something like:
feat(logging): configurable log level for username-taken signupsThis keeps the existing intent but adds a clear scope (
logging) and a concise, action-oriented description.Based on learnings, this helps generate a clearer changelog entry.
src/Options/index.js (1)
792-795: Clarify intended default and naming forlogLevels.usernameAlreadyExistsThe new option is wired and documented as:
- Comment +
:DEFAULT:say default is'error'.- Type:
usernameAlreadyExists: ?string;.From the linked issue, there was discussion about:
- Changing the default behavior to something less noisy (e.g.
info), and- A potential name like
signupUsernameTakento align withParse.Error.USERNAME_TAKEN.Can you double-check that:
The intended default log level for this event (for fresh installs and existing deployments) is indeed
'error', and that this matches:
- The default in
src/Options/Definitions.jsforLogLevels.usernameAlreadyExists, and- The fallback used in the middleware when no explicit value is configured.
The final option name
usernameAlreadyExistsis the agreed one vs.signupUsernameTaken, and if not, rename it consistently across:
types/Options/index.d.tssrc/Options/index.jssrc/Options/Definitions.js- Any runtime usage (e.g.
req.config.logLevels.usernameAlreadyExistsin middleware, tests).Aligning these keeps behavior, documentation, and configuration introspection in sync.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (6)
spec/ParseUser.spec.js(1 hunks)src/Options/Definitions.js(1 hunks)src/Options/docs.js(1 hunks)src/Options/index.js(1 hunks)src/middlewares.js(2 hunks)types/Options/index.d.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (3)
- src/middlewares.js
- src/Options/docs.js
- spec/ParseUser.spec.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.940Z
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-17T15:02:48.786Z
Learning: For Parse Server PRs, always suggest an Angular commit convention PR title that would make a meaningful changelog entry for developers. Update the PR title suggestion on every commit. The format should be: type(scope): description. Common types include feat, fix, perf, refactor, docs, test, chore. The scope should identify the subsystem (e.g., graphql, rest, push, security). The description should be action-oriented and clearly convey the change's impact to developers.
📚 Learning: 2025-11-08T13:46:04.940Z
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.940Z
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
🪛 Biome (2.1.2)
src/Options/index.js
[error] 792-792: 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). (15)
- GitHub Check: PostgreSQL 15, PostGIS 3.3
- GitHub Check: PostgreSQL 16, PostGIS 3.5
- GitHub Check: PostgreSQL 18, PostGIS 3.6
- GitHub Check: Node 20
- GitHub Check: MongoDB 7, ReplicaSet
- GitHub Check: PostgreSQL 15, PostGIS 3.4
- GitHub Check: PostgreSQL 17, PostGIS 3.5
- GitHub Check: MongoDB 8, ReplicaSet
- GitHub Check: Node 22
- GitHub Check: Redis Cache
- GitHub Check: MongoDB 6, ReplicaSet
- GitHub Check: PostgreSQL 15, PostGIS 3.5
- GitHub Check: Node 18
- GitHub Check: Docker Build
- GitHub Check: Benchmarks
🔇 Additional comments (2)
types/Options/index.d.ts (1)
294-301: LogLevels typings forusernameAlreadyExistslook consistent
usernameAlreadyExists?: string;matches the pattern of existingLogLevelsproperties and aligns with the new runtime option name; no typing issues here.src/Options/Definitions.js (1)
1479-1515: Definitions entry forusernameAlreadyExistsis consistentThe new
module.exports.LogLevels.usernameAlreadyExistsentry (env name, help text, anddefault: 'error') is consistent with the documentation insrc/Options/index.jsand with the existing LogLevels structure.Once you confirm the intended default level and naming in
src/Options/index.js, this definition will already be aligned.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/Options/Definitions.js (1)
1491-1496: Check intended default level and keep generator workflow in mindThe new
signupUsernameTakenentry is syntactically and stylistically consistent, but please double‑check thatdefault: 'error'and the help text ("Default iserror.") match the intended runtime behavior for USERNAME_TAKEN and any default used in the error‑handling middleware. If you actually want this event to default to a less noisy level such as'info', update the default and help text insrc/Options/index.jsand then re‑runnpm run definitionsso this file andsrc/Options/docs.jsare regenerated rather than edited directly.For the changelog, an Angular‑style PR title that fits this change could be:
feat(options): add log level for signup username taken.Based on learnings about Parse Server options and changelog conventions.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/Options/Definitions.js(1 hunks)src/Options/docs.js(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/Options/docs.js
🧰 Additional context used
🧠 Learnings (6)
📓 Common learnings
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.940Z
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-17T15:02:48.786Z
Learning: For Parse Server PRs, always suggest an Angular commit convention PR title that would make a meaningful changelog entry for developers. Update the PR title suggestion on every commit. The format should be: type(scope): description. Common types include feat, fix, perf, refactor, docs, test, chore. The scope should identify the subsystem (e.g., graphql, rest, push, security). The description should be action-oriented and clearly convey the change's impact to developers.
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.940Z
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.940Z
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.940Z
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
📚 Learning: 2025-12-02T06:55:53.808Z
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-12-02T06:55:53.808Z
Learning: When reviewing Parse Server PRs that add or modify Parse Server options, always verify that changes are properly reflected in three files: src/Options/index.js (where changes originate), src/Options/Definitions.js, and src/Options/docs.js. The correct workflow is: make changes in index.js first, then run `npm run definitions` to automatically replicate the changes to Definitions.js and docs.js.
Applied to files:
src/Options/Definitions.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: 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.
Applied to files:
src/Options/Definitions.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:
src/Options/Definitions.js
📚 Learning: 2025-05-04T20:41:05.147Z
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()`.
Applied to files:
src/Options/Definitions.js
⏰ 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). (16)
- GitHub Check: PostgreSQL 18, PostGIS 3.6
- GitHub Check: Node 22
- GitHub Check: PostgreSQL 15, PostGIS 3.5
- GitHub Check: PostgreSQL 15, PostGIS 3.4
- GitHub Check: Redis Cache
- GitHub Check: PostgreSQL 16, PostGIS 3.5
- GitHub Check: MongoDB 8, ReplicaSet
- GitHub Check: Node 20
- GitHub Check: PostgreSQL 17, PostGIS 3.5
- GitHub Check: PostgreSQL 15, PostGIS 3.3
- GitHub Check: MongoDB 7, ReplicaSet
- GitHub Check: Node 18
- GitHub Check: MongoDB 6, ReplicaSet
- GitHub Check: Docker Build
- GitHub Check: Code Analysis (javascript)
- GitHub Check: Benchmarks
|
Yes, I fixed the option file |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
src/Options/index.js (1)
792-795: NewLogLevels.signupUsernameTakenoption looks good; Biome error is a Flow parse false positive
- The new
signupUsernameTaken: ?stringproperty and its JSDoc are consistent with the existingLogLevelspattern and the PR goal; no changes needed here.- The Biome parse error (“Expected a statement but instead found '?'” at Line 792) is expected, because this file uses Flow type syntax (
?string) and Biome is parsing it as plain JS. If Biome is part of your tooling, consider configuring it for Flow or excludingsrc/Options/index.jsrather than changing the code.- Optional: since runtime behavior also treats a
'silent'value specially for this option, consider clarifying in the global log-level docs (or here) that'silent'is accepted, not just the standardLogLevelvalues, so users understand how to disable this log entirely.- Optional meta: to better fit the Angular-style convention for changelog entries, a PR title like
feat(logging): allow configuring signup username-taken log levelwould align with the repository style.
Based on learnings, the new option is correctly surfaced insrc/Options/index.jsandsrc/Options/docs.js; README updates are nice-to-have but not required for new options.src/Options/docs.js (1)
328-331:signupUsernameTakenJSDoc is correct; consider small clarity tweaksThe new
@property {String} signupUsernameTakenentry accurately documents the new option and default. Optionally, you could:
- Mention that this specifically controls logging for
Parse.Error.USERNAME_TAKEN(code 202), to make the mapping explicit.- If you decide to document
'silent'as a valid value for log-level overrides, reference that here as well so behavior and docs fully align.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
src/Options/Definitions.js(1 hunks)src/Options/docs.js(1 hunks)src/Options/index.js(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- src/Options/Definitions.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.940Z
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-17T15:02:48.786Z
Learning: For Parse Server PRs, always suggest an Angular commit convention PR title that would make a meaningful changelog entry for developers. Update the PR title suggestion on every commit. The format should be: type(scope): description. Common types include feat, fix, perf, refactor, docs, test, chore. The scope should identify the subsystem (e.g., graphql, rest, push, security). The description should be action-oriented and clearly convey the change's impact to developers.
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.940Z
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.940Z
Learnt from: mtrezza
Repo: parse-community/parse-server PR: 0
File: :0-0
Timestamp: 2025-11-08T13:46:04.940Z
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/index.js
🪛 Biome (2.1.2)
src/Options/index.js
[error] 792-792: 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). (16)
- GitHub Check: Benchmarks
- GitHub Check: MongoDB 8, ReplicaSet
- GitHub Check: Node 20
- GitHub Check: Node 18
- GitHub Check: Redis Cache
- GitHub Check: MongoDB 7, ReplicaSet
- GitHub Check: MongoDB 6, ReplicaSet
- GitHub Check: PostgreSQL 18, PostGIS 3.6
- GitHub Check: Node 22
- GitHub Check: PostgreSQL 15, PostGIS 3.5
- GitHub Check: PostgreSQL 15, PostGIS 3.4
- GitHub Check: PostgreSQL 17, PostGIS 3.5
- GitHub Check: PostgreSQL 15, PostGIS 3.3
- GitHub Check: PostgreSQL 16, PostGIS 3.5
- GitHub Check: Docker Build
- GitHub Check: Lint
|
Before merging, let me check if Parse Server 9 release can be done before that. |
3 participants
Pull Request
Issue
Fixes: #9329
Summary by CodeRabbit
New Features
Behavior
Tests
✏️ Tip: You can customize this high-level summary in your review settings.