fix(apps-engine): use typeof check for undefined in areRequiredSettingsSet#39334
fix(apps-engine): use typeof check for undefined in areRequiredSettingsSet#39334smirk-dev wants to merge 2 commits intoRocketChat:developfrom
Conversation
…gsSet The validation for required app settings was comparing against the string literal 'undefined' instead of checking for the actual undefined type. This meant that when sett.value was the JS primitive undefined, the comparison (undefined !== 'undefined') evaluated to true, causing the code to incorrectly treat unset required settings as already configured. Changed from: sett.value !== 'undefined' To: typeof sett.value !== 'undefined' This ensures apps cannot be enabled when required settings are missing.
|
Looks like this PR is not ready to merge, because of the following issues:
Please fix the issues and try again If you have any trouble, please check the PR guidelines |
🦋 Changeset detectedLatest commit: 9406775 The changes in this PR will be included in the next version bump. This PR includes changesets to release 42 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
WalkthroughFixed required-settings validation in AppManager: replaced a string-literal comparison against "undefined" with a robust Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Tip Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs). 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 |
…SettingsSet The previous fix (typeof check) correctly caught the string-literal 'undefined' comparison bug, but areRequiredSettingsSet still had two remaining bypasses: 1. null — typeof null === 'object', not 'undefined', so a packageValue of null passed the check and the setting was incorrectly treated as configured. 2. "" (empty string) — typeof '' === 'string', not 'undefined', so an empty string value also passed, again treating an unset setting as configured. The docstring explicitly states "not empty" is required for a value to count as set, but the implementation did not enforce this. Introduces a strict isValueSet guard (v !== undefined && v !== null && v !== '') and updates the test suite with 7 new cases covering the undefined, null, empty string, real value, and packageValue combinations.
There was a problem hiding this comment.
🧹 Nitpick comments (1)
packages/apps-engine/tests/server/AppManager.spec.ts (1)
299-388: Consider adding explicit tests for valid falsy values (falseand0).Right now, the suite verifies unset values well, but it doesn’t lock in that
false/0are still considered “set” (which the current guard intends).Proposed test additions
+ `@Test`('areRequiredSettingsSet - returns true when required setting value is false') + public areRequiredSettingsSetBooleanFalseValue() { + const manager = new AppManager({ + metadataStorage: this.testingInfastructure.getAppStorage(), + logStorage: this.testingInfastructure.getLogStorage(), + bridges: this.testingInfastructure.getAppBridges(), + sourceStorage: this.testingInfastructure.getSourceStorage(), + }); + + const storageItem = TestData.getAppStorageItem({ + settings: { + requiredSetting: { id: 'requiredSetting', type: 0, required: true, packageValue: undefined, value: false } as any, + }, + }); + + Expect((manager as any).areRequiredSettingsSet(storageItem)).toBe(true); + } + + `@Test`('areRequiredSettingsSet - returns true when required setting value is 0') + public areRequiredSettingsSetZeroValue() { + const manager = new AppManager({ + metadataStorage: this.testingInfastructure.getAppStorage(), + logStorage: this.testingInfastructure.getLogStorage(), + bridges: this.testingInfastructure.getAppBridges(), + sourceStorage: this.testingInfastructure.getSourceStorage(), + }); + + const storageItem = TestData.getAppStorageItem({ + settings: { + requiredSetting: { id: 'requiredSetting', type: 0, required: true, packageValue: undefined, value: 0 } as any, + }, + }); + + Expect((manager as any).areRequiredSettingsSet(storageItem)).toBe(true); + }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/apps-engine/tests/server/AppManager.spec.ts` around lines 299 - 388, Add explicit tests asserting that falsy-but-valid values are treated as "set" by areRequiredSettingsSet: create two new tests in AppManager.spec.ts that instantiate AppManager and build storageItem via TestData.getAppStorageItem with a requiredSetting (id 'requiredSetting') whose value is false (and another with value 0), and also variants where packageValue is false/0 and value is undefined/null; then Expect((manager as any).areRequiredSettingsSet(storageItem)).toBe(true) for each case to ensure false and 0 are considered valid set values.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@packages/apps-engine/tests/server/AppManager.spec.ts`:
- Around line 299-388: Add explicit tests asserting that falsy-but-valid values
are treated as "set" by areRequiredSettingsSet: create two new tests in
AppManager.spec.ts that instantiate AppManager and build storageItem via
TestData.getAppStorageItem with a requiredSetting (id 'requiredSetting') whose
value is false (and another with value 0), and also variants where packageValue
is false/0 and value is undefined/null; then Expect((manager as
any).areRequiredSettingsSet(storageItem)).toBe(true) for each case to ensure
false and 0 are considered valid set values.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: e9d08082-9a27-4028-b7c8-a4ad20d86004
📒 Files selected for processing (3)
.changeset/fix-apps-engine-required-settings-check.mdpackages/apps-engine/src/server/AppManager.tspackages/apps-engine/tests/server/AppManager.spec.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/apps-engine/src/server/AppManager.ts
📜 Review details
⏰ 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). (1)
- GitHub Check: cubic · AI code reviewer
🧰 Additional context used
📓 Path-based instructions (2)
**/*.{ts,tsx,js}
📄 CodeRabbit inference engine (.cursor/rules/playwright.mdc)
**/*.{ts,tsx,js}: Write concise, technical TypeScript/JavaScript with accurate typing in Playwright tests
Avoid code comments in the implementation
Files:
packages/apps-engine/tests/server/AppManager.spec.ts
**/*.spec.ts
📄 CodeRabbit inference engine (.cursor/rules/playwright.mdc)
**/*.spec.ts: Use descriptive test names that clearly communicate expected behavior in Playwright tests
Use.spec.tsextension for test files (e.g.,login.spec.ts)
Files:
packages/apps-engine/tests/server/AppManager.spec.ts
🧠 Learnings (11)
📚 Learning: 2025-10-06T20:30:45.540Z
Learnt from: d-gubert
Repo: RocketChat/Rocket.Chat PR: 37152
File: packages/apps-engine/tests/test-data/storage/storage.ts:101-122
Timestamp: 2025-10-06T20:30:45.540Z
Learning: In `packages/apps-engine/tests/test-data/storage/storage.ts`, the stub methods (updatePartialAndReturnDocument, updateStatus, updateSetting, updateAppInfo, updateMarketplaceInfo) intentionally throw "Method not implemented." Tests using these methods must stub them using `SpyOn` from the test library rather than relying on actual implementations.
Applied to files:
packages/apps-engine/tests/server/AppManager.spec.ts
📚 Learning: 2025-11-24T17:08:17.065Z
Learnt from: CR
Repo: RocketChat/Rocket.Chat PR: 0
File: .cursor/rules/playwright.mdc:0-0
Timestamp: 2025-11-24T17:08:17.065Z
Learning: Applies to apps/meteor/tests/e2e/**/*.spec.ts : Group related tests in the same file
Applied to files:
packages/apps-engine/tests/server/AppManager.spec.ts
📚 Learning: 2025-11-24T17:08:17.065Z
Learnt from: CR
Repo: RocketChat/Rocket.Chat PR: 0
File: .cursor/rules/playwright.mdc:0-0
Timestamp: 2025-11-24T17:08:17.065Z
Learning: Applies to apps/meteor/tests/e2e/**/*.spec.ts : Ensure tests run reliably in parallel without shared state conflicts
Applied to files:
packages/apps-engine/tests/server/AppManager.spec.ts
📚 Learning: 2025-11-24T17:08:17.065Z
Learnt from: CR
Repo: RocketChat/Rocket.Chat PR: 0
File: .cursor/rules/playwright.mdc:0-0
Timestamp: 2025-11-24T17:08:17.065Z
Learning: Applies to apps/meteor/tests/e2e/**/*.spec.ts : Utilize Playwright fixtures (`test`, `page`, `expect`) for consistency in test files
Applied to files:
packages/apps-engine/tests/server/AppManager.spec.ts
📚 Learning: 2025-11-24T17:08:17.065Z
Learnt from: CR
Repo: RocketChat/Rocket.Chat PR: 0
File: .cursor/rules/playwright.mdc:0-0
Timestamp: 2025-11-24T17:08:17.065Z
Learning: Applies to apps/meteor/tests/e2e/**/*.spec.ts : All test files must be created in `apps/meteor/tests/e2e/` directory
Applied to files:
packages/apps-engine/tests/server/AppManager.spec.ts
📚 Learning: 2025-11-24T17:08:17.065Z
Learnt from: CR
Repo: RocketChat/Rocket.Chat PR: 0
File: .cursor/rules/playwright.mdc:0-0
Timestamp: 2025-11-24T17:08:17.065Z
Learning: Applies to apps/meteor/tests/e2e/**/*.{ts,spec.ts} : Follow Page Object Model pattern consistently in Playwright tests
Applied to files:
packages/apps-engine/tests/server/AppManager.spec.ts
📚 Learning: 2025-11-24T17:08:17.065Z
Learnt from: CR
Repo: RocketChat/Rocket.Chat PR: 0
File: .cursor/rules/playwright.mdc:0-0
Timestamp: 2025-11-24T17:08:17.065Z
Learning: Applies to apps/meteor/tests/e2e/**/*.spec.ts : Use `expect` matchers for assertions (`toEqual`, `toContain`, `toBeTruthy`, `toHaveLength`, etc.) instead of `assert` statements in Playwright tests
Applied to files:
packages/apps-engine/tests/server/AppManager.spec.ts
📚 Learning: 2026-02-24T19:22:48.358Z
Learnt from: juliajforesti
Repo: RocketChat/Rocket.Chat PR: 38493
File: apps/meteor/tests/e2e/omnichannel/omnichannel-send-pdf-transcript.spec.ts:66-67
Timestamp: 2026-02-24T19:22:48.358Z
Learning: In Playwright end-to-end tests (e.g., under apps/meteor/tests/e2e/...), prefer locating elements by translated text (getByText) and ARIA roles (getByRole) over data-qa attributes. If translation values change, update the corresponding test locators accordingly. Never use data-qa locators. This guideline applies to all Playwright e2e test specs in the repository and helps keep tests robust to UI text changes and accessible semantics.
Applied to files:
packages/apps-engine/tests/server/AppManager.spec.ts
📚 Learning: 2026-02-26T19:25:44.063Z
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 38778
File: packages/ui-voip/src/providers/useMediaSession.ts:192-192
Timestamp: 2026-02-26T19:25:44.063Z
Learning: In the Rocket.Chat repository, do not reference Biome lint rules in code review feedback. Biome is not used even if biome.json exists; only reference Biome rules if there is explicit, project-wide usage documented. For TypeScript files, review lint implications without Biome guidance unless the project enables Biome rules.
Applied to files:
packages/apps-engine/tests/server/AppManager.spec.ts
📚 Learning: 2026-02-26T19:25:44.063Z
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 38778
File: packages/ui-voip/src/providers/useMediaSession.ts:192-192
Timestamp: 2026-02-26T19:25:44.063Z
Learning: In this repository (RocketChat/Rocket.Chat), Biome lint rules are not used even if a biome.json exists. When reviewing TypeScript files (e.g., packages/ui-voip/src/providers/useMediaSession.ts), ensure lint suggestions do not reference Biome-specific rules. Rely on general ESLint/TypeScript lint rules and project conventions instead.
Applied to files:
packages/apps-engine/tests/server/AppManager.spec.ts
📚 Learning: 2026-02-24T19:09:09.561Z
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 38974
File: apps/meteor/app/api/server/v1/im.ts:220-221
Timestamp: 2026-02-24T19:09:09.561Z
Learning: In RocketChat/Rocket.Chat OpenAPI migration PRs for apps/meteor/app/api/server/v1 endpoints, maintainers prefer to avoid any logic changes; style-only cleanups (like removing inline comments) may be deferred to follow-ups to keep scope tight.
Applied to files:
.changeset/fix-apps-engine-required-settings-check.md
🔇 Additional comments (2)
.changeset/fix-apps-engine-required-settings-check.md (1)
5-5: Changelog wording is accurate and release-friendly.This clearly captures the behavioral fix and the newly treated unset cases (
undefined,null,'').packages/apps-engine/tests/server/AppManager.spec.ts (1)
263-388: Great coverage for the required-settings regression.These cases directly validate the new
isValueSetbehavior and protect the enable/disable gate from the original bug class.
Changes
Fix a logic bug in
AppManager.areRequiredSettingsSet()where required app settings were never properly validated.Root Cause
In
packages/apps-engine/src/server/AppManager.ts(line 1121), the comparison checks against the string literal"undefined"instead of checking for the actualundefinedJavaScript primitive.When
sett.valueisundefined(the JS primitive), the expression evaluates incorrectly, causing the code to skip the setting — treating it as "already configured" when it is not.This means required app settings are never enforced, allowing apps to be enabled with missing required configuration.
Fix
Changed from direct string comparison to
typeofcheck, which correctly detects when values are actually unset.Testing
Summary by CodeRabbit
Bug Fixes
Tests
Documentation