fix: allow MCP bootstrap fields when adding service via update-database

[rshoemaker]

Summary

• The MCP validation layer blocked init_token and init_users on all update-database calls, but these fields need to be allowed when an MCP service is being added to an existing database for the first time.
• Fix: in validateDatabaseUpdate, check each service's ID against the existing spec. Services not yet in the deployment are treated as initial provisioning (isUpdate=false); services already deployed continue to reject bootstrap fields (isUpdate=true).
• Add TestValidateDatabaseUpdate_ServiceBootstrapFields covering the four cases: new service with bootstrap fields (allowed), no existing services with bootstrap fields (allowed), existing service with bootstrap fields (rejected), existing service without bootstrap fields (no error).

Test plan

• go test ./server/internal/api/apiv1/... passes
• Manual: create 1-node database, update-database to add MCP with init_token/init_users — accepted
• Manual: update-database on existing MCP service with init_token/init_users — rejected with 400

[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: cb8a0fcb-ed33-468b-a94d-105ff2eacadd

📥 Commits

Reviewing files that changed from the base of the PR and between bc20c0b and 05bcf4e.

📒 Files selected for processing (2)

• server/internal/api/apiv1/validate.go
• server/internal/api/apiv1/validate_test.go

---

📝 Walkthrough

Walkthrough

The validation logic in database update checks now distinguishes between newly-added services and existing services. Newly-added services allow MCP bootstrap fields (init_token, init_users), while existing services reject them to prevent unintended modifications to bootstrap-only configuration.

Changes

Cohort / File(s)

Summary

Bootstrap Fields Validation server/internal/api/apiv1/validate.go, server/internal/api/apiv1/validate_test.go

Refactored validateDatabaseUpdate to track existing service IDs and conditionally allow MCP bootstrap fields only for newly-added services. Updated service validation to pass isUpdate flag based on whether the service already exists. Added comprehensive test TestValidateDatabaseUpdate_ServiceBootstrapFields covering three scenarios: new service addition, updating existing service with bootstrap fields (error expected), and updating without bootstrap fields.

Poem

🐰 Hop, hop, hooray! A clever twist in the code—
New services get their bootstrap fields bestowed,
While old ones stand guard, saying "no, not today,"
First-time charm and eternal rules, the rabbit's way! 🌟

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically describes the main fix: allowing MCP bootstrap fields when adding a service via the update-database operation.
Description check	✅ Passed	The description covers the problem, solution, and test plan but lacks explicit documentation of the Testing and Checklist sections from the template.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ 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/PLAT-522/mcp_bootstrap_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.}