[DSIP-109][API&Alert] Optimize the alert strategy options for workflow execution to improve scalability

[njnu-seafish]

Was this PR generated or assisted by AI?

Yes，Part of the code was generated and optimized with the help of AI.

Purpose of the pull request

close #18298

Brief change log

1. Warning Type Multi-Selection Support

• Changed warning type from single selection to multi-selection
• Users can now select any combination of SUCCESS(1) , FAILURE(2) , and TIMEOUT(3) , or select none (stored as NULL )
• Frontend: Replaced RadioParam with SelectParam to support multiple selections

2. Database Storage Optimization

• Changed warning_type field from INT to varchar(64) in database
• Storage format: comma-separated string (e.g., "1,2" for SUCCESS and FAILURE)
• Migration: 0 → NULL , 1 → "1" , 2 → "2" , 3 → "1,2"

3. Workflow Instance Warning Type Logic

• Added hasWarningType(WarningType) method to check if a specific warning type is configured
• Added getWarningTypes() method to retrieve warning types as a list
• Used WarningTypeUtils for consistent parsing logic

4. Timeout Alert Optimization

• TaskTimeoutLifecycleEventHandler : Now checks if timeout warning is configured before sending alerts
• WorkflowTimeoutLifecycleEventHandler : Same optimization applied
• Eliminated duplicate code by using WorkflowInstance.hasWarningType(WarningType.TIMEOUT)

5. Internal Type Consistency

• Internal processing uses List for type safety
• API layer receives String from frontend and converts using WarningTypeUtils
• Database stores as String (comma-separated)

6. Frontend-Backend Alignment

• Modified workflow execution and scheduling forms to support multi-selection
• Default value changed from 'NONE' to null
• Ensured consistent behavior across manual trigger, schedule trigger, and backfill trigger

Verify this pull request

This pull request is code cleanup without any test coverage.

(or)

This pull request is already covered by existing tests, such as (please describe tests).

(or)

This change added tests and can be verified as follows:

(or)

Pull Request Notice

Pull Request Notice

If your pull request contains incompatible change, you should also add it to docs/docs/en/guide/upgrade/incompatible.md