Return success when status update target already matches
What does this MR do and why?
We have logs such as
'Can not require_input workflow that has status tool call approval required'
'Can not require_tool_call_approval workflow that has status tool call approval required'
These are causing unnecessary failures.
With this MR, status update endpoint returns success if the workflow already has the target status.
References
Closes gitlab-org/modelops/applied-ml/code-suggestions/ai-assist#1178 (closed)
Screenshots or screen recordings
How to set up and validate locally
Example:
- Create a workflow
curl POST --verbose \ --header "Authorization: Bearer $GDK_TOKEN" \ --header 'Content-Type: application/json' \ --data '{ "project_id": "flightjs/test-duo", "goal": "My goal", "agent_privileges": [1,2,5] }' \ http://gdk.test:3000/api/v4/ai/duo_workflows/workflows
- Start the workflow
curl --request PATCH --verbose \
--header "Authorization: Bearer $GDK_TOKEN" \
--header 'Content-Type: application/json' \
--data '{
"status_event": "start"
}' \
http://gdk.test:3000/api/v4/ai/duo_workflows/workflows/1526
- Send one more request to start (it's already in status: start)
curl --request PATCH --verbose \
--header "Authorization: Bearer $GDK_TOKEN" \
--header 'Content-Type: application/json' \
--data '{
"status_event": "start"
}' \
http://gdk.test:3000/api/v4/ai/duo_workflows/workflows/1526
You should not receive 400.
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Edited by Halil Coban