add alert query mode metadata

[nikhilsinhaparseable]

persist queryType for alerts: builder, code, or promql
defaults old alerts to builder
accepts legacy queryType=sql as code
reserves old creationType keys
treats builder/code as SQL modes for auth and dataset resolution

Summary by CodeRabbit

• New Features

  • Alerts now support a selectable query mode (builder, code, promql) via queryType/query_type, preserved across requests and responses.
  • Legacy "sql" continues to work as an alias for code; PromQL uses the provided dataset(s).

• Bug Fixes

  • Alert access checks now authorize using the full alert configuration (including query mode).
  • Stricter dataset access enforcement for PromQL; PromQL-backed threshold alerts are blocked in OSS.

• Chores

  • Improved request sanitization to cover queryType/query_type and related fields, plus added JSON parsing coverage for query mode.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: e7439157-14d9-4af0-9e20-290a25938c29

📥 Commits

Reviewing files that changed from the base of the PR and between 4cc0f7a and 39d85b4.

📒 Files selected for processing (1)

• src/alerts/mod.rs

🚧 Files skipped from review as they are similar to previous changes (1)

• src/alerts/mod.rs

---

Walkthrough

Adds AlertQueryType and threads it through alert requests, configs, alert traits, threshold alerts, and authorization. PromQL alerts use dataset-based handling and are rejected in OSS scheduling and validation paths. Alert access checks now use full alert configs instead of raw queries.

Changes

AlertQueryType: enum, structs, trait, and auth

Layer / File(s)	Summary
AlertQueryType enum and data contracts src/alerts/alert_enums.rs, src/alerts/alert_structs.rs, src/alerts/alert_traits.rs	Defines AlertQueryType with serde camelCase, default Builder, legacy "sql" alias for Code, and lowercase Display; adds query_type and datasets to AlertRequest; adds query_type to AlertConfig and AlertConfigResponse; extends reserved-field sanitization; adds the trait method contract.
Request conversion and ThresholdAlert updates src/alerts/alert_structs.rs, src/alerts/alert_types.rs	Branches AlertRequest::into on query_type for dataset resolution; sets query_type on AlertConfig; adds query_type to ThresholdAlert; carries query_type through conversions; rejects PromQL in OSS validation and scheduling paths.
Alert module parsing, loading, and dataset auth src/alerts/mod.rs	Adds user_auth_for_alert_config with query-type branching; refactors alert parsing and migration helpers; skips OSS-incompatible alerts during load; applies OSS schedulability checks before task creation; updates SSE broadcast eligibility and user-facing alert listing authorization.
HTTP alert handler authorization src/handlers/http/alerts.rs	Switches alert HTTP handlers from query-based authorization to config-based authorization; updates modify_alert to carry query_type into the persisted working config before rebuilding the alert.
Tests and minor formatting src/alerts/alert_enums.rs, src/lib.rs, src/metastore/metastore_traits.rs	Adds AlertQueryType deserialization tests including legacy alias and unknown mode rejection; reorders public re-exports in lib.rs; adds a trailing comma in Metastore::get_stream_json.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• parseablehq/parseable#1388: Shares the alert HTTP authorization and validation path that this PR changes to use alert configs.
• parseablehq/parseable#1389: Also touches src/alerts/mod.rs, including list_alerts_for_user, where this PR changes per-alert authorization.
• parseablehq/parseable#1408: Also changes AlertRequest::into dataset handling in src/alerts/alert_structs.rs.

Suggested labels

for next release

Poem

🐇 I hopped through alerts with a query-type grin,
Builder, Code, PromQL — let the branching begin!
Datasets now whisper which path they should take,
And old SQL aliases still bounce without break.
The rabbit approves: neat configs, no fuss,
With auth on the hop and no query for us!

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description captures key changes, but it omits the required template sections, issue reference, rationale, and checklist.	Rewrite it using the repo template: add Fixes #XXXX, a Description section with goal/rationale/key changes, and the testing/docs checklist.
Docstring Coverage	⚠️ Warning	Docstring coverage is 47.37% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title is concise and accurately summarizes the main change: adding alert query mode metadata.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/alerts/alert_types.rs`:
- Around line 94-97: The PromQL guard in validate() is too late because
Alerts::load still enqueues unsupported ThresholdAlert entries before
validation. Update the load/scheduling path so unsupported
AlertQueryType::Promql alerts are filtered out or marked disabled before
creating an AlertTask::Create, using the existing validate() /
AlertError::NotPresentInOSS logic as the source of truth. Make sure both
occurrences in alert_types.rs are covered so OSS never schedules PromQL alerts.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: bd53268e-dd27-4454-a46a-b83b6e7fb28d

📥 Commits

Reviewing files that changed from the base of the PR and between c54b762 and 3993a1d.

📒 Files selected for processing (8)

• src/alerts/alert_enums.rs
• src/alerts/alert_structs.rs
• src/alerts/alert_traits.rs
• src/alerts/alert_types.rs
• src/alerts/mod.rs
• src/handlers/http/alerts.rs
• src/lib.rs
• src/metastore/metastore_traits.rs

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/alerts/mod.rs`:
- Around line 153-162: The OSS alert loading path is aborting on unsupported
alert types because `load()` propagates errors from `alert_from_config_oss`, so
a single anomaly or forecast config stops later alerts from being loaded. Update
the alert-loading logic in `load()` to mirror the unschedulable-alert handling
below by skipping `AlertError::NotPresentInOSS` cases instead of returning
early, while keeping supported `Threshold` alerts loaded normally through
`alert_from_config_oss`.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 7ace9906-fea3-4fff-9edf-01fd115291fa

📥 Commits

Reviewing files that changed from the base of the PR and between 805e9bc and 4cc0f7a.

📒 Files selected for processing (1)

• src/alerts/mod.rs