Resolve dummy data initialization in script

[ansh-meesho]

🔁 Pull Request Template – BharatMLStack

Please fill out the following sections to help us review your changes efficiently.

Context:

Give a brief overview of the motivation behind this change. Include any relevant discussion links (Slack, documents, tickets, etc.) that help reviewers understand the background and the issue being addressed.

Describe your changes:

Mention the changes made in the codebase.

Testing:

Please describe how you tested the code. If manual tests were performed - please explain how. If automatic tests were added or existing ones cover the change - please explain how did you run them.

Monitoring:

Explain how this change will be tracked after deployment. Indicate whether current dashboards, alerts, and logs are enough, or if additional instrumentation is required.

Rollback plan

Explain rollback plan in case of issues.

Checklist before requesting a review

• I have reviewed my own changes?
• Relevant or critical functionality is covered by tests?
• Monitoring needs have been evaluated?
• Any necessary documentation updates have been considered?

📂 Modules Affected

• horizon (Real-time systems / networking)
• online-feature-store (Feature serving infra)
• trufflebox-ui (Admin panel / UI)
• infra (Docker, CI/CD, GCP/AWS setup)
• docs (Documentation updates)
• Other: ___________

---

✅ Type of Change

• Feature addition
• Bug fix
• Infra / build system change
• Performance improvement
• Refactor
• Documentation
• Other: ___________

---

📊 Benchmark / Metrics (if applicable)

Summary by CodeRabbit

• Refactor
  • Streamlined initialization workflow with conditional checks for optional dummy data initialization scripts, enabling graceful fallback to standard initialization paths.
  • Enhanced database verification with granular MySQL schema and user validation checks for more robust initialization validation.

[coderabbitai]

Walkthrough

The changes remove two complete database initialization scripts for etcd and scylla dummy data, refactor the main initialization orchestrator to conditionally execute dummy scripts with fallback logic, and enhance MySQL verification with a two-step schema and user existence check.

Changes

Cohort / File(s)	Summary
Removed Dummy Initialization Scripts quick-start/db-init/scripts/init-dummy-etcd.sh, quick-start/db-init/scripts/init-dummy-scylla.sh	Deleted etcd bootstrap script that configured feature store keys, entities, and model configurations (-233 lines). Deleted ScyllaDB initialization script that created tables and inserted example data (-124 lines).
Conditional Dummy Script Execution quick-start/db-init/scripts/main-init.sh	Added conditional existence checks for dummy initialization scripts (etcd, scylla, mysql) before execution. Falls back to regular initialization paths for scylla and etcd if dummy scripts are unavailable. (+17 lines, -3 lines)
Enhanced Database Verification quick-start/db-init/scripts/verify-init.sh	Replaced simple admin user existence check with two-step MySQL verification: first validate users table schema exists, then check for admin user presence. Provides granular status messages for each verification step. (+9 lines, -5 lines)

🚥 Pre-merge checks | ✅ 1 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Krd Checker	⚠️ Warning	PR description does not contain either a KRD link or a properly completed KRD exemption section with Pod Type and sufficient justification.	Add either a KRD Google Doc link or complete the KRD Exemption section with Pod Type (H0/H1/H2) and 20+ character justification.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Dynamic Configuration Validation	✅ Passed	No changes to files matching the pattern application-dyn-*.yml exist in this pull request. All modifications are limited to shell scripts in quick-start/db-init/scripts/.

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

---

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

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

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

Inline comments:
In `@quick-start/db-init/scripts/verify-init.sh`:
- Around line 16-24: The final MySQL summary is hardcoded to assume the admin
exists; update verify-init.sh to compute a reusable status string after the
existing MySQL checks (use the ADMIN_COUNT result and the schema check) — e.g.,
set a variable like MYSQL_STATUS to either "admin user ✅" or "schema ready (no
admin user) ✅" based on ADMIN_COUNT and the table presence check, and then
reference that MYSQL_STATUS variable in the script's final summary output
instead of the fixed message; locate logic around the mysql check and the
ADMIN_COUNT variable to implement this change.

---

ℹ️ Review info

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b2a88fb and 10844e0.

📒 Files selected for processing (4)

• quick-start/db-init/scripts/init-dummy-etcd.sh
• quick-start/db-init/scripts/init-dummy-scylla.sh
• quick-start/db-init/scripts/main-init.sh
• quick-start/db-init/scripts/verify-init.sh

💤 Files with no reviewable changes (2)

• quick-start/db-init/scripts/init-dummy-scylla.sh
• quick-start/db-init/scripts/init-dummy-etcd.sh

[rajanyo-paul-meesho]

@coderabbitai

Is this PR a bug fix? A bug fix corrects existing broken functionality.

Examples of bug fixes: fixing crashes, correcting logic errors, fixing broken UI.

Examples of NOT bug fixes: new features, refactoring, cleanup, docs, tests, performance improvements.

Respond with JSON only:
{{
"confidence": <float 0.0-1.0>,
"reasoning": ""
}}

Important:

• confidence must be derived from your reasoning and represents the probability that this PR is a bug fix (not confidence in your writing).
• Your reasoning and confidence must be consistent.
• If your reasoning concludes it is NOT a bug fix (e.g., upgrade, feature, refactor, docs/tests/perf/CI), set confidence <= 0.2.
• If your reasoning concludes it IS a bug fix (fixes incorrect behavior, errors, crashes, broken UI), set confidence >= 0.8.
• If uncertain, use a moderate confidence in 0.3-0.7.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

@rajanyo-paul-meesho

{
    "confidence": 0.15,
    "reasoning": "This PR removes unused dummy data initialization scripts and updates main-init.sh to conditionally check for their existence. The changes are primarily cleanup/refactoring rather than fixing broken functionality. While the branch name includes 'fix/', the actual changes remove scripts and add graceful fallbacks, which is more characteristic of technical debt cleanup than a bug fix."
}