fix: don't error remote database status command if database was not enabled yet to provide more meaningful output

[pieh]

🎉 Thanks for submitting a pull request! 🎉

Summary

---

For us to review and ship your PR efficiently, please perform the following steps:

• Open a bug/issue before writing your code 🧑‍💻. This ensures we can discuss the changes and get feedback from everyone that should be involved. If you`re fixing a typo or something that`s on fire 🔥 (e.g. incident related), you can skip this step.
• Read the contribution guidelines 📖. This ensures your code follows our style guide and
  passes our tests.
• Update or add tests (if any source code was changed or added) 🧪
• Update or add documentation (if features were changed or added) 📝
• Make sure the status checks below are successful ✅

A picture of a cute animal (not mandatory, but encouraged)

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: fba479dc-c9f7-42f5-9dad-1c74881b3922

📥 Commits

Reviewing files that changed from the base of the PR and between 6b0ffd0 and bf68be1.

📒 Files selected for processing (1)

• src/commands/database/util/applied-migrations.ts

---

📝 Walkthrough

Summary by CodeRabbit

• Bug Fixes

  • Avoids unnecessary remote database requests when a site has no configured database; status now reports zero applied/pending migrations for branch paths without attempting remote fetches.

• Tests

  • Added unit test verifying branch-path behavior when the database is disabled, ensuring no remote fetches or connections occur and correct status output.

• Refactor

  • Improved handling of nullable migration data to safely return an empty list when none exist.

Walkthrough

The PR changes the --branch path in the database status command so remote branch connection-string and remote applied-migrations are fetched only when the site reports a configured database (siteHasDatabase true). If the site has no database, the command skips remote requests and uses an empty applied-migrations result. The remoteAppliedMigrations util now guards against data.migrations being null/undefined and returns an empty array in that case. A unit test was added to verify behavior when Netlify Database is disabled (siteDatabase: null).

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: preventing errors in the remote database status command when database is not enabled, allowing meaningful output.
Description check	✅ Passed	The description is related to the changeset as it refers to the database status command improvements, though it primarily contains a contributor checklist template rather than detailed implementation details.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/database-status-branch-not-yet-created

---

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

[github-actions]

📊 Benchmark results

Comparing with 30d4ef0

• Dependency count: 1,061 (no change)
• Package size: 357 MB (no change)
• Number of ts-expect-error directives: 355 (no change)

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/commands/database/db-status.ts`:
- Around line 418-421: Remove the explanatory inline comments and make the
intent explicit in code: replace the commented assignment with a clearly named
noop function (e.g., const noopFetchApplied = async () => []; ) and assign
fetchApplied = noopFetchApplied (or directly use fetchApplied = async () => []),
removing the comment lines entirely so the code reads self-documentingly; update
any nearby references to use the new symbol if introduced.

In `@tests/unit/commands/database/db-status.test.ts`:
- Line 773: The test uses an invalid matcher by expecting a Promise<void> to
"resolves.not.toThrow()"; update the assertion to check the resolved value
instead: call statusDb with createMockCommand() and replace the matcher with
"resolves.toBeUndefined()" so the promise resolution for statusDb({ branch:
'feature-x' }, createMockCommand()) is asserted correctly.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 635136a6-44a3-4f75-8109-fbb7cacda462

📥 Commits

Reviewing files that changed from the base of the PR and between 3deb552 and ae8c1fc.

📒 Files selected for processing (2)

• src/commands/database/db-status.ts
• tests/unit/commands/database/db-status.test.ts

[pieh]

This explicitly is not using enabled check, because when used with @netlify/database-proxy and NETLIFY_DB_URL (IIRC) it is reported as true even if database is not actually created yet, so fetchBranchConnectionString that is hitting an API would return failure.

The enabled logic might need some more thinking about desired interaction with @netlify/database-proxy, but this seems a bit out of scope for this change.