[bug]: Rules manager initiate() silently drops alerts for subsequent orgs when an org has no rules

[MannanSaood]

Bug description

In a multi-org SigNoz deployment, when the rule manager initializes at startup (initiate()), it iterates over all organizations to load their stored alert rules. However, if any organization in the list has no rules, the function executes return nil immediately. This silently terminates the entire startup loop, abandoning all subsequent organizations and their rules.

Affected code — pkg/query-service/rules/manager.go, lines 262–264:

		if len(storedRules) == 0 {
			return nil // BUG: exits the entire function instead of just skipping this org
		}

As a result, any organization that happens to be iterated after an empty-rules org will have zero alert rules loaded at startup. All alerts for those orgs are silently lost.

Expected behaviour

When an organisation has no stored rules (len(storedRules) == 0), the loop should skip that organisation and continue processing rules for all remaining organisations. No alerts from any organisation should be silently dropped at startup.
The code should be:

		if len(storedRules) == 0 {
			continue
		}

How to reproduce

1. Create two organisations in SigNoz (multi-org setup).
2. In the first organisation (the one that appears first in the database), do not create any alert rules.
3. In the second organisation, create at least one alert rule.
4. Restart the SigNoz query-service / backend.
5. Observe: The second organisation's alert rules are not scheduled for evaluation after startup, and no error is logged.

Version information

• Signoz version: v0.132.0 (current main branch, introduced in commit 91cbd1727551621a863828b7280f5f7e15b39ca7)
• Browser version: N/A (Backend issue)
• Your OS and version: Any (Linux/macOS/Docker)
• Your CPU Architecture(ARM/Intel): Any

Additional context

The default sharder (noopsharder) returns the full key range [0, MaxUint32], so ListByOwnedKeyRange returns all organisations in the database. This means the bug is active in every standard self-hosted deployment that has more than one organisation.

This was likely a copy-paste oversight from when this function was refactored from a single-org loop to a multi-org loop (PR #8107). The impact is a silent failure where the system appears healthy but monitoring coverage is dropped for subsequent organisations.

[Harsh23Kashyap]

I'd like to take this. The fix is a 1-line change in pkg/query-service/rules/manager.go — replace return nil with continue so the loop skips empty orgs and continues processing the rest. Confirmed the cited line 262-264 is correct (the issue's line numbers are slightly off, but the code is exactly as described). I'll add a small unit test covering the multi-org case and open a PR.

[Harsh23Kashyap]

Opened PR #12084 for this. The cited line was 263 in current main (you said 267–269), but the code was exactly as you described.

[MannanSaood]

I'd like to take this. The fix is a 1-line change in pkg/query-service/rules/manager.go — replace return nil with continue so the loop skips empty orgs and continues processing the rest. Confirmed the cited line 262-264 is correct (the issue's line numbers are slightly off, but the code is exactly as described). I'll add a small unit test covering the multi-org case and open a PR.

I have already created a PR to fix this, which has not been approved by the maintainers yet. So please check the PR attached to this

[MannanSaood]

Opened PR #12084 for this. The cited line was 263 in current main (you said 267–269), but the code was exactly as you described.

I think the will flag this as a replica of #12060 which is the fix PR i have created

[kunalrawat425]

Hi, I noticed this issue and opened a fix in #11840.

The one-line change replaces return nil with continue in Manager.initiate so an org with zero stored rules is skipped rather than causing the function to exit and abandon every subsequent org's rules.

Added TestInitiateVisitsAllOrgsWhenSomeHaveNoRules which fails on the old code (only 1 org visited) and passes with the fix (both orgs visited). Happy to adjust based on review feedback.