langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 12:05:30 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

[PR #26850] Feat/add status filter to workflow runs #31589

New Issue
Closed
opened 2026-02-21 20:49:45 -05:00 by yindo · 0 comments
yindo commented 2026-02-21 20:49:45 -05:00
Owner
Copy Link
Copy Source

Original Pull Request: https://github.com/langgenius/dify/pull/26850

State: closed
Merged: Yes

Important

  1. Make sure you have read our contribution guidelines
  2. Ensure there is an associated issue and you have been assigned to it
  3. Use the correct syntax to link this PR: Fixes #<issue number>.

Fixes #26849

Summary

This PR adds optional status filtering, time range filtering, and count statistics endpoints to the workflow run console API. This enhancement allows developers to:

  1. Filter workflow runs by status - Query workflow runs with an optional status parameter (running, succeeded, failed, stopped, partial-succeeded)
  2. Filter by time range - Query workflow runs created within a specific time range (e.g., 7d, 4h, 30m, 30s)
  3. Get count statistics - New endpoints to retrieve total counts and breakdown by status, with optional time range filtering
  4. Monitor long-running workflows - Identify workflows that are still running after a certain period
  5. Improve API usability - Backward compatible changes that make it easier to monitor and analyze workflow execution

Changes Made

API Endpoints Enhanced:

  • GET /console/api/apps/{app_id}/workflow-runs - Added optional status query parameter
  • GET /console/api/apps/{app_id}/advanced-chat/workflow-runs - Added optional status query parameter
  • GET /console/api/apps/{app_id}/workflow-runs/count - New endpoint for count statistics with optional status and time_range filters
  • GET /console/api/apps/{app_id}/advanced-chat/workflow-runs/count - New endpoint for advanced chat count statistics with optional status and time_range filters

New Features:

  • Time Range Filtering: Filter workflow runs by created_at timestamp using intuitive time duration format
    • Supported formats: 7d (7 days), 4h (4 hours), 30m (30 minutes), 30s (30 seconds)
    • Filters based on created_at field to include all workflow runs regardless of status
    • Can be combined with status filter for powerful queries

Implementation Layers:

  • Controller:
    • Added status and time_range parameter parsing
    • Added count endpoint handlers with comprehensive API documentation
    • Custom input validation for time duration format
  • Service:
    • Implemented count methods with status and time range filter support
    • Passes filters through to repository layer
  • Repository:
    • Added get_workflow_runs_count() method with SQL aggregation using GROUP BY
    • Time filtering implemented at database level using WHERE created_at >= threshold
    • Efficient query construction with proper index usage
  • Fields:
    • Added workflow_run_count_fields response field definitions
  • Utils:
    • Added libs/time_parser.py for parsing time duration strings
    • Added libs/custom_inputs.py for Flask-RESTX input validation
    • Uses timezone-aware datetime (UTC) to avoid deprecation warnings

API Examples

List with status filter:

GET /console/api/apps/{app_id}/workflow-runs?status=succeeded&limit=20

Get all status counts:

GET /console/api/apps/{app_id}/workflow-runs/count

Response:
{
  "total": 10,
  "running": 2,
  "succeeded": 5,
  "failed": 2,
  "stopped": 1,
  "partial-succeeded": 0
}

Get specific status count:

GET /console/api/apps/{app_id}/workflow-runs/count?status=succeeded

Response:
{
  "total": 5,
  "running": 0,
  "succeeded": 5,
  "failed": 0,
  "stopped": 0,
  "partial-succeeded": 0
}

Get counts for recent workflow runs (last 7 days):

GET /console/api/apps/{app_id}/workflow-runs/count?time_range=7d

Response:
{
  "total": 50,
  "running": 5,
  "succeeded": 35,
  "failed": 8,
  "stopped": 2,
  "partial_succeeded": 0
}

Use Cases

  1. Performance Monitoring: Track workflow completion rates over different time periods
  2. Alerting: Identify workflows that have been running for too long
  3. Troubleshooting: Quickly find recent failures for debugging
  4. Dashboard Integration: Power real-time monitoring dashboards with accurate statistics
  5. Capacity Planning: Analyze workflow execution patterns over time

Technical Details

Database Query Optimization:

  • All filtering happens at the database level (no post-fetch filtering)
  • Uses existing indexes on created_at, status, tenant_id, app_id
  • Efficient GROUP BY aggregation for count statistics
  • No additional database columns or migrations required

Backward Compatibility:

  • All new parameters are optional
  • Existing API calls continue to work without changes
  • No breaking changes to response formats

Code Quality:

  • Follows existing code patterns and conventions
  • Uses timezone-aware datetime (UTC) per Python 3.12+ best practices
  • Comprehensive error handling and input validation
  • All code passes ruff linting and `basedpyright

Screenshots

Not applicable - API-only changes with no UI modifications.

Before After
... ...

Checklist

  • This change requires a documentation update, included: Dify Document
  • I understand that this PR may be closed in case there was no previous discussion or issues. (This doesn't apply to typos!)
  • I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
  • I've updated the documentation accordingly.
  • I ran dev/reformat(backend) and cd web && npx lint-staged(frontend) to appease the lint gods

The console API is only for self-hosting; there is no existing API documentation.

image Image Image Image
**Original Pull Request:** https://github.com/langgenius/dify/pull/26850 **State:** closed **Merged:** Yes --- > [!IMPORTANT] > > 1. Make sure you have read our [contribution guidelines](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) > 1. Ensure there is an associated issue and you have been assigned to it > 1. Use the correct syntax to link this PR: `Fixes #<issue number>`. Fixes [#26849 ](https://github.com/langgenius/dify/issues/26849) ## Summary <!-- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change. --> This PR adds optional **status filtering**, **time range filtering**, and **count statistics endpoints** to the workflow run console API. This enhancement allows developers to: 1. **Filter workflow runs by status** - Query workflow runs with an optional `status` parameter (running, succeeded, failed, stopped, partial-succeeded) 2. **Filter by time range** - Query workflow runs created within a specific time range (e.g., 7d, 4h, 30m, 30s) 3. **Get count statistics** - New endpoints to retrieve total counts and breakdown by status, with optional time range filtering 4. **Monitor long-running workflows** - Identify workflows that are still running after a certain period 5. **Improve API usability** - Backward compatible changes that make it easier to monitor and analyze workflow execution ### Changes Made **API Endpoints Enhanced:** - `GET /console/api/apps/{app_id}/workflow-runs` - Added optional `status` query parameter - `GET /console/api/apps/{app_id}/advanced-chat/workflow-runs` - Added optional `status` query parameter - `GET /console/api/apps/{app_id}/workflow-runs/count` - **New endpoint** for count statistics with optional `status` and `time_range` filters - `GET /console/api/apps/{app_id}/advanced-chat/workflow-runs/count` - **New endpoint** for advanced chat count statistics with optional `status` and `time_range` filters **New Features:** - **Time Range Filtering**: Filter workflow runs by `created_at` timestamp using intuitive time duration format - Supported formats: `7d` (7 days), `4h` (4 hours), `30m` (30 minutes), `30s` (30 seconds) - Filters based on `created_at` field to include all workflow runs regardless of status - Can be combined with status filter for powerful queries **Implementation Layers:** - **Controller**: - Added `status` and `time_range` parameter parsing - Added count endpoint handlers with comprehensive API documentation - Custom input validation for time duration format - **Service**: - Implemented count methods with status and time range filter support - Passes filters through to repository layer - **Repository**: - Added `get_workflow_runs_count()` method with SQL aggregation using GROUP BY - Time filtering implemented at database level using `WHERE created_at >= threshold` - Efficient query construction with proper index usage - **Fields**: - Added `workflow_run_count_fields` response field definitions - **Utils**: - Added `libs/time_parser.py` for parsing time duration strings - Added `libs/custom_inputs.py` for Flask-RESTX input validation - Uses timezone-aware datetime (UTC) to avoid deprecation warnings ### API Examples **List with status filter:** ```http GET /console/api/apps/{app_id}/workflow-runs?status=succeeded&limit=20 ``` Get all status counts: ``` GET /console/api/apps/{app_id}/workflow-runs/count Response: { "total": 10, "running": 2, "succeeded": 5, "failed": 2, "stopped": 1, "partial-succeeded": 0 } ``` Get specific status count: ``` GET /console/api/apps/{app_id}/workflow-runs/count?status=succeeded Response: { "total": 5, "running": 0, "succeeded": 5, "failed": 0, "stopped": 0, "partial-succeeded": 0 } ``` Get counts for recent workflow runs (last 7 days): ``` GET /console/api/apps/{app_id}/workflow-runs/count?time_range=7d Response: { "total": 50, "running": 5, "succeeded": 35, "failed": 8, "stopped": 2, "partial_succeeded": 0 } ``` ### Use Cases 1. **Performance Monitoring**: Track workflow completion rates over different time periods 2. **Alerting**: Identify workflows that have been running for too long 3. **Troubleshooting**: Quickly find recent failures for debugging 4. **Dashboard Integration**: Power real-time monitoring dashboards with accurate statistics 5. **Capacity Planning**: Analyze workflow execution patterns over time ### Technical Details **Database Query Optimization:** - All filtering happens at the database level (no post-fetch filtering) - Uses existing indexes on `created_at`, `status`, `tenant_id`, `app_id` - Efficient GROUP BY aggregation for count statistics - No additional database columns or migrations required **Backward Compatibility:** - All new parameters are optional - Existing API calls continue to work without changes - No breaking changes to response formats **Code Quality:** - Follows existing code patterns and conventions - Uses timezone-aware datetime (UTC) per Python 3.12+ best practices - Comprehensive error handling and input validation - All code passes `ruff` linting and `basedpyright ## Screenshots Not applicable - API-only changes with no UI modifications. | Before | After | |--------|-------| | ... | ... | ## Checklist - [x] This change requires a documentation update, included: [Dify Document](https://github.com/langgenius/dify-docs) - [x] I understand that this PR may be closed in case there was no previous discussion or issues. (This doesn't apply to typos!) - [x] I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change. - [x] I've updated the documentation accordingly. - [x] I ran `dev/reformat`(backend) and `cd web && npx lint-staged`(frontend) to appease the lint gods The console API is only for self-hosting; there is no existing API documentation. <img width="642" height="615" alt="image" src="https://github.com/user-attachments/assets/307686f8-c06c-4d62-9e53-e394d2c1e1d7" /> <img width="1533" height="448" alt="Image" src="https://github.com/user-attachments/assets/a74ae1f9-c399-4add-b556-5cfe94fb2cac" /> <img width="1512" height="503" alt="Image" src="https://github.com/user-attachments/assets/2b8bfcd3-d49d-4b0d-99c6-e8722facc066" /> <img width="1532" height="868" alt="Image" src="https://github.com/user-attachments/assets/95db2782-6625-4ba1-8d9b-3fc90f029fe2" />
yindo added the pull-request label 2026-02-21 20:49:45 -05:00
yindo closed this issue 2026-02-21 20:49:45 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#31589
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?