feat(deleter): count live resources that block a project or org delete

[AmanGIT07]

Summary

Adds ProjectResourceBlockers and OrganizationResourceBlockers to the cascade deleter. Each returns one RESOURCES_EXIST blocker per namespace, with Count set to the number of live resources that the app.deletion rules say block the delete. Both return nothing while the block is disabled. Nothing calls them yet. Stacked on #2004.

Changes

• core/deleter/deleter.go: BlockerResourcesExist, SubjectResourceNamespace and Blocker.Count. A resource blocker has no message; a client builds the text from the namespace in Subject and from Count.
• core/deleter/resource_blockers.go:
  • The project check lists the project's live resources and applies the project rules.
  • The organization check lists the organization's own resources and the resources of every project in the organization, disabled projects included, and applies the organization rules to all of them.
  • A resource blocks unless its rule is allow, or its rule is block_unless_deletable and its metadata has the boolean "deletable": true. A namespace or delete with no rule blocks.
  • Blockers are sorted by namespace.

A project with two compute/machine resources (project: block) and one compute/order resource without "deletable": true (project: block_unless_deletable) gets:

[]deleter.Blocker{
	{Type: "RESOURCES_EXIST", Subject: "compute/machine", SubjectType: "resource_namespace", Count: 2},
	{Type: "RESOURCES_EXIST", Subject: "compute/order", SubjectType: "resource_namespace", Count: 1},
}

Test Plan

• core/deleter/service_test.go TestProjectResourceBlockers: nothing is read while disabled; counts per namespace, where only the boolean deletable: true counts and a namespace or delete with no rule blocks; nothing blocks; a list error.
• TestOrganizationResourceBlockers: nothing is read while disabled; the organization's own and its projects' resources are judged by the organization rules, with counts added across projects; list errors for the organization's resources, its projects, and a project's resources.
• go test ./core/deleter/... passes.
• golangci-lint run ./... reports no issues.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
frontier	Ready	Preview	Oct 20, 2026 8:16am UTC

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Repository: raystack/frontier/.coderabbit.yaml
• Review profile: CHILL
• Plan: Advanced
• Run ID: 5fa1b909-5007-444b-82d1-961d64e4e129

📥 Commits

Reviewing files that changed from the base of the PR and between 32d339a and 2f35048.

📒 Files selected for processing: 3

• core/deleter/deleter.go
• core/deleter/resource_blockers.go
• core/deleter/service_test.go

Included review availability: This review used your included allowance. Your plan provides up to 2 included reviews per hour; 1 remain after this review.

📝 Summary

Summary by CodeRabbit

• New Features

  • Project and organization deletion now reports blocking resources grouped by namespace.
  • Blockers include the number of resources preventing deletion.
  • Resources can be allowed or marked as deletable through applicable rules and metadata.
  • Deletion blocker behavior can be disabled through configuration.

• Bug Fixes

  • Resource-listing failures are now returned when evaluating deletion blockers.

The change adds resource-existence blockers for project and organization deletion. It applies configured rules to resources, groups blocking resources by namespace, and reports their counts. Tests cover blocker behavior and resource-listing errors.

Changes: Deletion blockers

Layer / File(s)	Summary
Resource blocker evaluation core/deleter/deleter.go, core/deleter/resource_blockers.go, core/deleter/service_test.go	Adds resource-existence blocker fields and project and organization blocker methods. The methods apply namespace rules, aggregate counts, and wrap listing errors. Tests cover configuration, resource metadata, empty results, and listing errors.

Priority: ⬇️ Low

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Feature

Suggested reviewers: whoabhisheksah

Merge Risk: ⚪ Minimal · up to 2f350

The blocker checks appear ready to merge after normal checks; the investigated counting and disabled-project concerns do not require changes.

Pre-merge checks: 2

Check name	Status	Explanation
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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

[coveralls]

Coverage Report for CI Build 39391455810

Coverage increased (+0.06%) to 55.547%

Details

• Coverage increased (+0.06%) from the base build.
• Patch coverage: 53 of 53 lines across 1 file are fully covered (100%).
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	41842
Covered Lines:	23242
Line Coverage:	55.55%
Coverage Strength:	19.27 hits per line

---

💛 - Coveralls

[rohilsurana]

Looks good. It matches the agreed design, and the final config works with no code change, as you said. The small notes are inline.

One question: transfer, download and store have no project rule, so a project that holds one can never be deleted. That is fine while they stay org scoped. Can you confirm Courier will never attach them to a project?

Two test cases are missing: an org with no projects, and a project with no resources.

[AmanGIT07]

transfer, download and store have no project rule, so a project that holds one can never be deleted. [...] Can you confirm Courier will never attach them to a project?

Yes. They are registered with CreateOrganizationResource, so they never have a project. If that ever changes, the config gets a project rule for them, with no code change.

Two test cases are missing: an org with no projects, and a project with no resources.

Added both in b265947.