fix: Allow chaos probes with same name across different projects

[khushi1310]

Fixes #5242
Fixes #5035

What you expected to happen

1. Should be able to create chaos probes with the same name in different projects since project scope should be independent
2. Should be able to reuse probe names after deleting the old probe

Root Cause

Issue 1 - Database Index:
The MongoDB index for the chaosProbes collection had a unique constraint on the name field alone, which prevented probes with the same name from existing across different projects.

Issue 2 - Application Validation:
The ValidateUniqueProbe function was not filtering out deleted probes (is_removed: true) when checking for name uniqueness, preventing name reuse after deletion.

Changes Made

1. Database Index Fix (init.go)

File: chaoscenter/graphql/server/pkg/database/mongodb/init.go

Old Index Configuration:

• Unique index on name only (global uniqueness across all projects)
• Separate non-unique index on project_id

New Index Configuration:

• Compound unique index on (name, project_id) - allows same probe names in different projects
• Added partial filter expression { is_removed: false } - deleted probes don't interfere with uniqueness

2. Application Validation Fix (handler.go)

File: chaoscenter/graphql/server/pkg/probe/handler/handler.go

Added {"is_removed", false} to the validation query in ValidateUniqueProbe function so that deleted probes are not counted when checking for name uniqueness.

Before:

query := bson.D{
    {"name", probeName},
    {"project_id", bson.D{{"$eq", projectID}}},
}

After:

query := bson.D{
    {"name", probeName},
    {"project_id", bson.D{{"$eq", projectID}}},
    {"is_removed", false},
}

What This Ensures

✅ Probe names can be reused across different projects
✅ Probe names remain unique within each project
✅ Deleted probes don't block name reuse
✅ Application-level validation aligns with database-level constraints

Migration Required for Existing Installations

⚠️ IMPORTANT: The database index fix only applies to new installations. Existing deployments need to manually update the MongoDB index.

For Existing Production Users:

If you're upgrading from a previous version, connect to your MongoDB instance and run:

use litmus

// Drop the old problematic index
db.chaosProbes.dropIndex("name_1")

// Verify the new index exists (created automatically on app restart)
db.chaosProbes.getIndexes()

The new compound index will be automatically created when the application restarts with the updated code.

For New Installations:

No action required - the correct index will be created automatically.

How to reproduce the bugs (before fix):

Bug 1:

1. Create a chaos probe named "test-probe" in Project A
2. Attempt to create another probe named "test-probe" in Project B
3. Error: E11000 duplicate key error

Bug 2:

1. Create a probe named "test-probe" in Project A
2. Delete the probe
3. Try to create a new probe named "test-probe" in Project A
4. Error: "The name test-probe is not unique and was already used before"

Testing (after fix):

1. Create a probe named "test-probe" in Project A ✅
2. Create a probe with the same name "test-probe" in Project B ✅ (now works!)
3. Try creating another "test-probe" in Project A ❌ (correctly fails - must be unique within project)
4. Delete the probe in Project A and create a new one with same name ✅ (now works!)

Files Changed

1. chaoscenter/graphql/server/pkg/database/mongodb/init.go - Updated index definition for chaosProbes collection
2. chaoscenter/graphql/server/pkg/probe/handler/handler.go - Added is_removed filter to validation query

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I have read the CONTRIBUTING doc
• I have signed the commit for DCO to be passed.
• Lint and unit tests pass locally with my changes
• [] I have added tests that prove my fix is effective or that my feature works (if appropriate)
• I have added necessary documentation (if appropriate)

[khushi1310]

@PriteshKiri @amityt @SahilKr24 the build-pipeline workflow failed due to a security vulnerability detected by Trivy in the Docker image
CVE-2025-47907 in the Go stdlib package (database/sql: Postgres Scan Race Condition). Affected version: v1.22.12. Fixed in: v1.23.12, v1.24.6.

I have changed the go version to 1.24.6
It builds successfully and all tests pass locally on my end.
I'd really appreciate it if someone could take a look!

Whether updating the Go version in this PR is the correct way to handle the build failure, or if I should approach it differently.

@PriteshKiri Can you please run the workflow again, If the fix seems fine

[khushi1310]

@PriteshKiri I have reverted the go version changes, as that are causing unit test failures.
This vulnerability failure is pre existing and not related to the issue raised.
Need your help with this !
Thanks !

[amityt]

Thanks for the fix @khushi1310 ! 🚀

[amityt]

@SarthakJain26 Can you please validate if the index changes are breaking change or not!

[SarthakJain26]

These changes will partially solve the issue, since for existing installations, mongo will already have the existing index where name is set as unique. To tackle this, we need an upgrade script in https://github.com/litmuschaos/litmus/tree/master/chaoscenter/upgrade-agents to remove the existing index from chaosProbes collection.

For newer installations it will work fine.

[khushi1310]

db.chaosProbes.dropIndex("name_1")

yes @SarthakJain26 I have mentioned this in the PR description as well, and are there any naming conventions that needs to be followed for that script ?
will this work ? fix-index-probe.js
This command I think would help for removing the old indexes on unique name
db.chaosProbes.dropIndex("name_1")

Please do let me know if I need to do this or the current code fixing new installations would work ?

[SarthakJain26]

@khushi1310 this PR looks good, and thanks for adding the process in the description. This is what user also needs to do, and the automated process to do this is via the upgrade-agent that I mentioned. If you are interested you can raise a separate PR to add the same logic to drop the index in the upgrade-agent module.
I'll be happy to help if you need any 🙌 .

[khushi1310]

@khushi1310 this PR looks good, and thanks for adding the process in the description. This is what user also needs to do, and the automated process to do this is via the upgrade-agent that I mentioned. If you are interested you can raise a separate PR to add the same logic to drop the index in the upgrade-agent module. I'll be happy to help if you need any 🙌 .

sure @SarthakJain26 I'll open a new PR for the same. Thanks for the clarification.