[kirtimanmishrazipstack]

What

• New api/deployment/aggregate/ and pipeline/aggregate/: counts by status (success, error, never run, inactive), the failing count and up to 100 failing rows. Pipelines also get not_scheduled.
• Both lists and both aggregates take 5 new optional filters: status, owner, last_run_after, last_run_before, failing.

Why

• The Frontend v1 API deployment and pipeline pages need the counts and filters (P4-T01 to P4-T03).
• The list params are in scope: the PB phase goal allows new optional parameters, PB-T13's aggregate takes the list's filters, and P4-T01 needs them on the list. They are not in the published spec.

How

• The rules live in workflow_v2/list_aggregates.py. The aggregate counts the list's own filtered rows, so total always equals the list's count.
• The failing rule is the dashboard's (failing_streaks.py). A stopped run counts as error in the status counts but breaks a failing streak.
• The contract is in backend/api_v2/README.md and backend/pipeline_v2/README.md. JSON Schemas for both responses are in each app's contract/, and tests validate real responses against them. They are not in the published client spec.

Can this break any existing features. If yes, please list possible items. If no, please explain why. (PS: Admins do not merge the PR without this section filled)

• pipeline/ now answers bad input with a 400: a malformed workflow (was a 500) and an unknown type (was an empty list). A blank type is now ignored (was an empty list). The frontend sends none of these.
• Other requests: no. Without the new params, both lists run the same SQL and return the same response as before. A test pins the new filter step, and review-deep compared the list SQL with the merge base at aac8a907e.

Database Migrations

• None. No new index.

Env Config

• None.

Relevant Docs

• backend/api_v2/README.md, backend/pipeline_v2/README.md

Related Issues or PRs

• UN-4320, epic UN-4257

Dependencies Versions

• Test group only: rfc3339-validator, so the contract tests check date-time fields.

Notes on Testing

• api_v2, pipeline_v2, workflow_v2 and dashboard_metrics tests: 487 passed, including the spec drift test.
• Tested on the running backend over HTTP with seeded data, 90 checks passed: counts, every filter, bad input, detail routes, auth and the 100-row cap. Only the default user and a platform key were used, as the OSS login accepts no other user; other callers' views are covered by tests.
• The published spec (specs/docstudio-oss.json) is unchanged. The new filters are for the frontend; publishing them later would be an addition, not a break.
• The query plans haven't been checked on staging-sized data yet.

Screenshots

Checklist

I have read and understood the Contribution Guidelines.

🤖 Generated with Claude Code

[kirtimanmishrazipstack]

UN-4320 [FEAT] Status counts and new filters for the API deployment and pipeline lists. Head aac8a907e, merge base 8765a4dcb, 20 files, 1603 lines (count matches GitHub). Base fetched this run. The branch is behind main and merges cleanly.

Verdict — REQUEST CHANGES

Summary — Critical: 0 · High: 1 · Medium: 12 · Lenses run: 19/19. Low findings are left out of this post.

Security deep-dive: done. No findings at confidence >= 8; this is a precision-biased scan, not a clean bill of health.

boundary-sweep: 14 sinks traced, clean.

Tests run with real Postgres and Redis: 268 passed plus 76 subtests, matching the PR's count, and the set also passed in reverse order. The spec drift test passes. Of 25 deliberate code changes on a scratch copy, 20 failed a test and 5 did not. Four of those five are in findings #1, #2, #12 and #13.

The core logic held up: org scoping, total equal to the list's count (582 deployment and 756 pipeline filter combinations, no mismatches), the status counts, and the failing=true and failing_count agreement. Without the new params, list SQL matched the merge base in all 24 caller and param combinations tried.

The numbered findings are in the inline comments.

Lens checklist

• Lens 1: See findings #3, #11
• Lens 2: Clean
• Lens 3: See findings #2, #4, #5, #6, #7
• Lens 4: Clean
• Lens 5: N/A — no migrations and no writes; both new endpoints only read
• Lens 6: Clean
• Lens 7: See findings #2, #5, #10, #11
• Lens 8: N/A — no external calls, retries, queues or buffers added
• Lens 9: See findings #4
• Lens 10: Clean
• Lens 11: Clean
• Lens 12: N/A — no model calls, prompts or agents touched
• Lens 13: See findings #1, #12, #13
• Lens 14: N/A — no dependency manifest or build file changed; croniter is already a dependency
• Lens 15: Clean
• Lens 16: See findings #6, #8, #9, #10
• Lens 17: Clean
• Lens 18: N/A — no chart, on-prem values, on-prem settings or on-prem build path touched
• Lens 19: N/A — no worker concurrency, autoscaling, grace or pool setting touched

Assessed by the orchestrator: lenses 4, 5, 6, 8, 11, 12, 14, 17, 18, 19, and lens 7's consumer search.

Lens 7 search: frontend/src, workers, the python client and the cloud repo have no caller of the aggregates yet, and none sends the new param names to detail routes. The planned consumers are P4-T01 to P4-T03. unstract-cli was not checked.

Lens 15 gate, pinned versions, check-only, on the changed files: ruff 0.3.4 check and format with the hook's --force-exclude, pycln 2.6.0 and markdownlint-cli 0.42.0 all pass. pyupgrade was not run because it has no check mode.

Lens 17: the merge-result sweep exited 1 for the 11 rule identifiers I swept (failing_only, failing_streaks, next_run_time, not_scheduled and others). The dashboard README's failing rule and its callers agree with this diff, and no other restatement disagrees.

Open questions for the author

1. Should status=error count a run someone stopped on purpose? The PR says so openly, but failing_streaks.py:L9-L13 argues a stop isn't a failure, and the pipeline card renders STOPPED in a neutral colour. The abort feature in #2415 will make stopped runs common.
2. Should never_run exclude rows with a run in flight? See #9.
3. Should an active pipeline with an impossible schedule count in not_scheduled? See #7.

Assumptions made

• #1 is High because lens 13 anchors a test that is the only coverage of a stated rule at High; today's code is correct.
• #3 is Medium rather than High because P4-T01 needs these filters and they are optional. If the spec owner rejects them, the fix grows.
• No caller outside the repos searched sends the new param names to a detail route. If one does, #2 becomes High.

[kirtimanmishrazipstack]

UN-4320 [FEAT] Status counts and new filters for the API deployment and pipeline lists. Follow-up review. Head 26507abde, merge base 8765a4dcb, 22 files, 2020 lines (count matches GitHub). Base fetched this run. Changes since my last review start at aac8a907e.

Verdict — REQUEST CHANGES

Summary — Critical: 0 · High: 1 · Medium: 4 · Low: 5 · Lenses run: 19/19. The Medium count includes #3 and #7, still partly open from the first review. Of the 13 prior findings, 11 are resolved; the status of each is in its own thread.

Scope change — YES. The new commit adds two contract files and new 400 answers on existing pipeline routes, so I re-checked it on all 19 lenses.

Security deep-dive: done. No findings at confidence >= 8; this is a precision-biased scan, not a clean bill of health.

boundary-sweep: 3 sinks traced, clean.

Tests run with real Postgres and Redis: api_v2, pipeline_v2, workflow_manager/workflow_v2 and dashboard_metrics, 486 passed and 118 subtests passed. Of 19 deliberate code changes on a scratch copy, 18 failed a test. The survivor is #15.

New findings #14 to #16 are in the inline comments. #16 is on a line the first review covered and missed.

Low findings

• #17 pipeline_v2/views.py:L136-L141: get_queryset checks type and workflow on every action, so GET, PATCH or DELETE pipeline/<pk>/?type=bogus is now a 400 (it was a 404), while ?status=bogus is ignored. Run the two checks only for LIST_FILTER_ACTIONS, or name the detail routes in the Errors tables.
• #18 pipeline_v2/openapi_schema.py:L45-L57: the aggregate has no auth=, so it generates cookie and basic auth. The deployment twin declares platformKey.
• #19 list_aggregate_serializers.py:L66: Django raises at .filter(), inside the exception handler, which turns it into a 500. Delete the comment; the docstring states the behaviour.
• #20 list_aggregate_serializers.py:L44, L81, api_v2/serializers.py:L653, pipeline_v2/serializers/aggregate.py:L9, specs/docstudio-oss.json:L531: "ended in error" in an API whose error status also counts STOPPED. Say "ended in ERROR; a STOPPED run breaks the streak", as api_v2/README.md:L76 does.
• #21 pipeline_v2/views.py:L72-L76: the unknown-type 400 could name the accepted values.

Lens checklist

• Lens 1: See findings #15
• Lens 2: Clean
• Lens 3: See findings #21
• Lens 4: Clean
• Lens 5: N/A — no migration, model field or write; the *.schema.json files are API contracts
• Lens 6: Clean
• Lens 7: See findings #14, #16, #17, #18
• Lens 8: N/A — no external calls, retries, queues or buffers added
• Lens 9: Clean
• Lens 10: Clean
• Lens 11: Clean
• Lens 12: N/A — no model calls, prompts or agents touched
• Lens 13: See findings #14, #15
• Lens 14: N/A — no dependency manifest or lockfile changed
• Lens 15: Clean
• Lens 16: See findings #14, #15, #19, #20
• Lens 17: Clean
• Lens 18: N/A — no chart, on-prem values, on-prem settings or on-prem build path touched
• Lens 19: N/A — no worker concurrency, autoscaling, grace or pool setting touched

Assessed by the orchestrator: lenses 4, 5, 6, 8, 11, 12, 14, 17, 18, 19, and lens 7's consumer search.

Lens 7 search: the frontend sends type.toUpperCase() and a workflow UUID; unstract-python-client and the public docs use the uppercase types; workers call the separate internal pipeline routes; unstract-cloud has no caller. unstract-cli was not checked.

Lens 15 gate, pinned versions, check-only, on the changed files: ruff 0.3.4 check and format, pycln 2.6.0, markdownlint-cli 0.42.0 and a JSON parse all pass.

Lens 17: the merge-result sweep against origin/main exited 1 for 15 identifiers from this commit. No hit disagrees because of this diff.

Open questions

1. #3 waits on the spec owner's decision, to be recorded on UN-4320.
2. Frames A02 and A08 show the Status menu counts and the failing banner while a status filter is applied. The aggregate can fill both only when called without status and failing; UN-4312's failing_count ignores those filters on the server instead. Should the README say so for P4-T01?

[kirtimanmishrazipstack]

Answers to the open questions in the follow-up review:

1. connectors #3: the question and my recommendation are in its thread, which stays open for the ticket owner's decision. The decision will be recorded in the UN-4320 Jira comment.
2. Frames A02 and A08: yes. Both READMEs now say to call the aggregate without status and failing to fill the status counts and the failing list (5b3660b, api_v2/README.md:L39-L40, pipeline_v2/README.md:L34-L35). The server keeps applying every filter, so total still equals the list's count.

[kirtimanmishrazipstack]

UN-4320 [FEAT] Status counts and new filters for the API deployment and pipeline lists. Third review (follow-up). Head 6d9956a9b, merge base 8765a4dcb, 23 files, 1992 lines (count matches GitHub). Base fetched this run. Changes since my last review start at 26507abde. The branch is 49 commits behind main and merges cleanly.

Verdict — APPROVE WITH NITS

Summary — Critical: 0 · High: 0 · Medium: 0 · Low: 9 · Lenses run: 19/19 (5 N/A). The Low count includes #17 to #21, still open from the second review. Of the 16 numbered findings from the first two reviews, 15 are resolved and #7 is waived; the status of each changed one is in its own thread.

Scope change — YES. The new commits add a test dependency (rfc3339-validator), so I re-checked the since-review diff on all 19 lenses.

Security deep-dive: done. No findings at confidence >= 8; this is a precision-biased scan, not a clean bill of health.

boundary-sweep: 0 sinks traced, clean. The since-review diff adds no log line, error path, endpoint or outbound call.

Tests run with real Postgres and Redis: api_v2, pipeline_v2, workflow_manager/workflow_v2 and dashboard_metrics, 486 passed and 118 subtests passed. account_v2/test_product_preference.py, whose date-time checks the new dependency turns on, 17 passed. Of 5 deliberate code changes on a scratch copy, 4 failed a test. The survivor is #25.

New findings #22 to #25 are in the inline comments.

Still open from the second review (Low)

• #17 pipeline_v2/views.py:L136-L141: type and workflow are still checked on every action, so ?type=bogus on a detail route is a 400.
• #18 pipeline_v2/openapi_schema.py:L47-L62: the pipeline aggregate still has no auth=.
• #19 list_aggregate_serializers.py:L66: the comment still says Django raises on evaluation.
• #20: "ended in error" is unchanged at all 5 sites.
• #21 pipeline_v2/views.py:L72-L76: the unknown-type 400 still does not name the accepted values.

Unanchored findings

• #3's decision (keep the new filters out of the published spec; the routes keep them for the frontend) is recorded only in its PR thread. UN-4320 has no comments yet; record it in the ticket's Jira comment.

Lens checklist

• Lens 1: Clean
• Lens 2: Clean
• Lens 3: See findings #21
• Lens 4: Clean
• Lens 5: N/A — no migration, model field or write; both new endpoints only read
• Lens 6: Clean
• Lens 7: See findings #17, #18, #23, #24
• Lens 8: N/A — no external calls, retries, queues or buffers added
• Lens 9: Clean
• Lens 10: Clean
• Lens 11: Clean
• Lens 12: N/A — no model calls, prompts or agents touched
• Lens 13: See findings #25
• Lens 14: Clean
• Lens 15: See findings #22
• Lens 16: See findings #19, #20, #22, #23, #24
• Lens 17: See findings #22
• Lens 18: N/A — no chart, on-prem values, on-prem settings or on-prem build path touched
• Lens 19: N/A — no worker concurrency, autoscaling, grace or pool setting touched

Assessed by the orchestrator: lenses 4, 5, 6, 8, 11, 12, 14, 17, 18, 19, and lens 7's consumer search.

Lens 7 search: no caller sends the new params or calls the aggregates in frontend/src, workers, unstract-cloud, unstract-sdk, unstract-python-client, unstract-docs or unstract-ui-test-automation. unstract-cli was not checked.

Lens 14: rfc3339-validator 0.1.4 is in the test group only, MIT licensed and hash-pinned in uv.lock; its one dependency, six, was already locked. The lock header moved from revision = 3 to 5. The pinned uv 0.6.14 used by backend.Dockerfile (uv sync --locked) and CI accepts it: uv lock --check exited 0.

Lens 15 gate, pinned versions, check-only, on the since-review files: ruff 0.3.4 check and format with --force-exclude, pycln 2.6.0 and markdownlint-cli 0.42.0 (--disable MD013, as hooked) all pass, and pyproject.toml parses.

Lens 17: the merge-result sweep against origin/main exited 1 for 7 identifiers from the since-review diff. #22 is the only hit that disagrees because of this diff.

Assumptions

• CI's spec drift test runs under the OSS settings.

[kirtimanmishrazipstack]

On the third review's unanchored finding: #3's decision (the new filters stay out of the published spec; the routes keep them for the frontend) will be recorded in the UN-4320 Jira comment when the ticket moves to In Review, after human review.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
2.3% Duplication on New Code

See analysis details on SonarQube Cloud