fix: handle support for partial success introduce in dbt 1.9 with microbatching

[nicor88]

Fix #1894
Tweaked unit tests to handle the new model failure.

Remarks

I didn't validate that the above works in a real prod environment, anyhow remove the new Enum value for partial success and run the unit tests changed in this PR, I was able to get the exactly same error that I had in production.
FAILED tests/unit/monitor/api/alerts/test_alert_filters.py::test_filter_alerts - ValueError: 'partial success' is not a valid Status
Putting back the enum value, let the unit test run properly.

Summary by CodeRabbit

• New Features

  • Added a "Partial Success" status option for monitoring alerts.

• Tests

  • Extended test data with an additional pending alert (microbatch-tagged) and expanded alert-filter tests to include this case across tag, owner, model, and name-based filters, updating expected counts and ID lists.

[github-actions]

👋 @nicor88
Thank you for raising your pull request.
Please make sure to add tests and document all user-facing changes.
You can do this by editing the docs files in this pull request.

[coderabbitai]

Walkthrough

Added a new enum member PARTIAL_SUCCESS = "partial success" to the Status enum in the data monitoring schema. Tests were updated to include a new pending/model alert (model_alert_4) with status "partial success" and to adjust expected results across multiple alert-filter unit tests.

Changes

Cohort / File(s)	Change Summary
Schema enum extension elementary/monitor/data_monitoring/schema.py	Added new enum member PARTIAL_SUCCESS = "partial success" to the Status enumeration.
Test data and assertions tests/unit/monitor/api/alerts/test_alert_filters.py	Added a new PendingAlertSchema entry (model_alert_4) containing a ModelAlertDataSchema payload with tags: ["microbatch"] and status: "partial success". Updated many filter tests to include model_alert_4 in expected results and adjusted counts and ID lists for tag-, owner-, model-, and node-name-based filters and combined filter scenarios.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Areas to inspect closely:
  • elementary/monitor/data_monitoring/schema.py — ensure enum serialization/deserialization and any downstream consumers accept the new value.
  • tests/unit/monitor/api/alerts/test_alert_filters.py — verify the new test data (model_alert_4) and all adjusted assertions reflect intended behavior for microbatch/partial-success alerts.
  • Any other codepaths that pattern-match status strings or rely on exhaustive Status values.

Poem

🐰
A half-hop through the data field,
Partial success the microbatch yield,
New status stitched, alerts rearranged,
Tests updated, behaviors changed—
I nibble code and cheer the tweak, 🥕

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The PR title "fix: handle support for partial success introduce in dbt 1.9 with microbatching" is directly related to the main changeset. The title accurately describes the primary objective: adding support for the "partial success" status introduced in dbt 1.9 with microbatching. The changes add a PARTIAL_SUCCESS enum member to the Status enumeration and update tests to handle this new status across filter scenarios. The title is specific and clear enough that a reviewer scanning the history would immediately understand the primary change being made. While there is a minor grammatical issue ("introduce" should be "introduced"), the title remains meaningful and directly conveys the purpose of the changes.
Linked Issues Check	✅ Passed	The PR directly addresses the coding requirements from linked issue #1894. The issue specifies that Elementary ~=0.18.0 does not fully support dbt v1.9 microbatches and fails when encountering the "partial success" status. The PR resolves this by adding the PARTIAL_SUCCESS enum member to the Status enumeration in schema.py, which enables Elementary to recognize and handle this new status without failing. Additionally, the unit tests are updated to include a model alert with the "partial success" status and verify that the new status is correctly handled across multiple filter scenarios, ensuring the new functionality works as expected. These changes directly meet the requirement to handle the new dbt status and allow Elementary to run successfully with microbatched incremental runs.
Out of Scope Changes Check	✅ Passed	All changes in the PR are directly aligned with the requirements from linked issue #1894. The addition of the PARTIAL_SUCCESS enum member is the core change needed to support the new dbt v1.9 status, and the test updates in test_alert_filters.py ensure the new status is properly integrated into the filtering logic and tested across various scenarios. No unrelated changes, refactorings, or feature additions outside the scope of supporting the "partial success" status are present. The changes are minimal, focused, and directly address the stated objective of handling microbatches in dbt v1.9.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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 and usage tips.}

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

tests/unit/monitor/api/alerts/test_alert_filters.py (1)

855-876: Update assertions to account for the new partial success alert.

With model_alert_4 added (status "partial success"), the default filter now excludes two model alerts: model_alert_3 (skipped) and model_alert_4 (partial success). The assertions need updating.

Apply this diff:

     assert len(filter_test_alerts) == len(test_alerts)
-    assert len(filter_model_alerts) == len(model_alerts) - 1  # 1 skipped model alert
+    assert len(filter_model_alerts) == len(model_alerts) - 2  # 1 skipped, 1 partial success

     # Test that passing no filter returns all the alerts.
     filter_test_alerts = filter_alerts(test_alerts)
     filter_model_alerts = filter_alerts(model_alerts)
     assert len(filter_test_alerts) == len(test_alerts)
-    assert len(filter_model_alerts) == len(model_alerts) - 1  # 1 skipped model alert
+    assert len(filter_model_alerts) == len(model_alerts) - 2  # 1 skipped, 1 partial success

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between ba986eb and 3b95137.

📒 Files selected for processing (2)

• elementary/monitor/data_monitoring/schema.py (1 hunks)
• tests/unit/monitor/api/alerts/test_alert_filters.py (2 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

tests/unit/monitor/api/alerts/test_alert_filters.py (4)

elementary/monitor/fetchers/alerts/schema/pending_alerts.py (3)

• PendingAlertSchema (35-94)
• AlertTypes (23-26)
• AlertStatus (29-32)

elementary/monitor/fetchers/alerts/schema/alert_data.py (1)

• ModelAlertDataSchema (234-286)

elementary/monitor/data_monitoring/schema.py (4)

• ResourceType (27-30)
• FiltersSchema (146-342)
• FilterSchema (62-126)
• FilterType (33-37)

elementary/monitor/api/alerts/alert_filters.py (1)

• filter_alerts (80-95)

🔇 Additional comments (2)

elementary/monitor/data_monitoring/schema.py (1)

24-24: LGTM, but verify default filter behavior.

The enum addition is correct and follows the existing naming convention. However, note that PARTIAL_SUCCESS is not included in the default status filter (lines 137-143), meaning alerts with this status will be excluded by default—similar to SKIPPED. Please confirm this is the intended behavior for microbatch partial success statuses.

tests/unit/monitor/api/alerts/test_alert_filters.py (1)

235-261: LGTM, but this addition will impact existing tests.

The new alert with status="partial success" is correctly structured and serves to test the new PARTIAL_SUCCESS status. However, be aware that:

1. The default filter excludes PARTIAL_SUCCESS (like SKIPPED), so tests at lines 863 and 869 will need updating
2. If node names are extracted from model_unique_id, the test at line 757 might also be affected

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

tests/unit/monitor/api/alerts/test_alert_filters.py (1)

879-894: LGTM! Default filter correctly excludes both skipped and partial success.

The updated logic properly accounts for the new "partial success" status being excluded by default filters, alongside "skipped" status. The comment and assertion changes are accurate and well-documented.

Consider adding an explicit test case that filters by Status.PARTIAL_SUCCESS to ensure the new enum value works correctly in positive filtering scenarios, similar to the existing status filter tests (lines 788-824). This would provide comprehensive coverage for the new status value.

Example:

filter = FiltersSchema(
    statuses=[StatusFilterSchema(values=[Status.PARTIAL_SUCCESS], type=FilterType.IS)]
)
filter_model_alerts = filter_alerts(model_alerts, filter)
assert len(filter_model_alerts) == 1
assert filter_model_alerts[0].id == "model_alert_4"

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between e5c9f32 and 9bc7374.

📒 Files selected for processing (1)

• tests/unit/monitor/api/alerts/test_alert_filters.py (14 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

tests/unit/monitor/api/alerts/test_alert_filters.py (3)

elementary/monitor/fetchers/alerts/schema/pending_alerts.py (3)

• PendingAlertSchema (35-94)
• AlertTypes (23-26)
• AlertStatus (29-32)

elementary/monitor/data_monitoring/schema.py (2)

• ResourceType (27-30)
• FiltersSchema (146-342)

elementary/monitor/api/alerts/alert_filters.py (1)

• filter_alerts (80-95)

🔇 Additional comments (2)

tests/unit/monitor/api/alerts/test_alert_filters.py (2)

235-261: LGTM! Well-structured test fixture for microbatch partial success.

The new model_alert_4 correctly represents a microbatch incremental model with "partial success" status, providing comprehensive test coverage for the dbt v1.9 feature. All required fields are properly populated, and the distinct owner ("alice") and model_id ("model_id_3") enable effective filtering test scenarios.

---

389-392: LGTM! All test updates correctly account for model_alert_4.

The updated assertions throughout all filter test scenarios are accurate:

• Tag-based filters correctly include/exclude model_alert_4 based on its ["microbatch"] tag
• Owner-based filters correctly handle the new "alice" owner
• Model-based filters correctly recognize "model_id_3"
• Status-based IS_NOT filters correctly include "partial success" as it differs from FAIL/WARN/ERROR
• Node name filter correctly matches "model_id_3"

All expected counts and sorted ID lists have been properly adjusted.

Also applies to: 414-416, 439-444, 474-479, 504-508, 540-544, 604-606, 628-632, 696-698, 720-723, 777-778, 837-841