[SILO-701] chore: improve tests for module and cycles feature check

[Saurabhkmr98]

Description

• chore: improve tests for module and cycles feature check

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Improvement (change that would cause existing functionality to not work as expected)
• Code refactoring
• Performance improvements
• Documentation update

Screenshots and Media (if applicable)

Test Scenarios

References

Summary by CodeRabbit

• Tests
  • Improved test setup to ensure module-related features are properly enabled before test execution, enhancing test reliability.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

The test setup hook in module.test.ts is enhanced to verify and enable the module_view feature on the target project before running tests. If the feature is disabled, the hook automatically enables it.

Changes

Cohort / File(s)	Summary
Test Setup Enhancement tests/unit/module.test.ts	Updated BeforeAll hook to retrieve the target project and conditionally set module_view: true if it's currently disabled, ensuring module features are enabled for test execution.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

• Review the logic for retrieving and updating the project configuration in the setup hook
• Verify the conditional check for module_view status is correct
• Confirm the update operation won't cause side effects on other tests

Poem

🐰 A module view must be seen,
Before tests hop upon the scene,
With checks and updates, swift and spry,
We'll make sure features pass on by! ✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: improving tests for module and cycles feature check by ensuring module_view is enabled in BeforeAll.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch chore-add_feature_enable_validation

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[makeplane]

Linked to Plane Work Item(s)

• [SILO-701] Improve node sdk for feature enabled checks

This comment was auto-generated by Plane

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

tests/unit/module.test.ts (1)

20-20: Consider checking for undefined explicitly.

The condition !project.module_view treats undefined the same as false. If the property doesn't exist or is undefined, this will trigger an update that might not be necessary.

Apply this diff for more explicit checking:

-    if (!project.module_view) {
+    if (project.module_view === false || project.module_view === undefined) {

Or more concisely:

-    if (!project.module_view) {
+    if (project.module_view !== true) {

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e921689 and b67c93a.

📒 Files selected for processing (1)

• tests/unit/module.test.ts (1 hunks)

🔇 Additional comments (1)

tests/unit/module.test.ts (1)

19-24: No action needed—cycle tests already have the parallel feature check.

Verification confirms that tests/unit/cycle.test.ts (lines 26-31) already implements the same feature check pattern: it retrieves the project, checks cycle_view, and updates it if needed. Both test files now follow the identical safety pattern for their respective features.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Add error handling for project retrieval and update operations.

The API calls to retrieve and update the project lack error handling. If either operation fails, the tests will proceed with potentially incorrect assumptions about feature availability, leading to confusing test failures.

Apply this diff to add proper error handling:

-    const project = await client.projects.retrieve(workspaceSlug, projectId);
-    if (!project.module_view) {
-      await client.projects.update(workspaceSlug, projectId, {
-        module_view: true,
-      });
-    }
+    try {
+      const project = await client.projects.retrieve(workspaceSlug, projectId);
+      if (!project.module_view) {
+        await client.projects.update(workspaceSlug, projectId, {
+          module_view: true,
+        });
+      }
+    } catch (error) {
+      throw new Error(`Failed to ensure module_view is enabled: ${error}`);
+    }

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	const project = await client.projects.retrieve(workspaceSlug, projectId);
	if (!project.module_view) {
	await client.projects.update(workspaceSlug, projectId, {
	module_view: true,
	});
	}
	try {
	const project = await client.projects.retrieve(workspaceSlug, projectId);
	if (!project.module_view) {
	await client.projects.update(workspaceSlug, projectId, {
	module_view: true,
	});
	}
	} catch (error) {
	throw new Error(`Failed to ensure module_view is enabled: ${error}`);
	}

🤖 Prompt for AI Agents

In tests/unit/module.test.ts around lines 19 to 24, the project retrieval and
update API calls lack error handling; wrap the await
client.projects.retrieve(...) and the conditional client.projects.update(...) in
try/catch blocks (or chain .catch) and fail the test or rethrow with a clear
message when an error occurs, e.g., capture and include the original error when
calling retrieve or update, assert that project exists before using
project.module_view, and ensure any failure aborts the test (use throw new Error
or test framework's fail/expect to stop further execution).