Allow setting the DagRun state in create DAGRun API

[SamWheating]

closes: #30075

This allows incoming API requests to create DAGs in non-queued states (running, success, failed), which is more consistent with the documentation.

As-per the original issue, I'm not sure whether:

• The code is wrong (in which case this is the correct fix)
• The documentation generated from the OpenAPI spec is wrong (which is due to the reference overriding the readOnly attribute here, as described here).

Let me know what you think, and if you think that this functionality is undesirable then I can update my PR to simply fix the API Docs.

Tested in Breeze by creating several non-queued DAGRuns via the API.

[ephraimbuddy]

We shouldn't allow users to create dagruns with states other than queued. I'm not seeing a protection from users creating dagruns with other states

[SamWheating]

We shouldn't allow users to create dagruns with states other than queued. I'm not seeing a protection from users creating dagruns with other states

This goes back to my original question about whether this is a bug in the spec or a bug in the implementation.

If there's only one acceptable value for a field then there's no point in exposing it as a read-write field, and we should just keep this as read-only and fix the spec. I will open a separate PR for that, and you can merge one or the other.

[ephraimbuddy]

We shouldn't allow users to create dagruns with states other than queued. I'm not seeing a protection from users creating dagruns with other states

This goes back to my original question about whether this is a bug in the spec or a bug in the implementation.

If there's only one acceptable value for a field then there's no point in exposing it as a read-write field, and we should just keep this as read-only and fix the spec. I will open a separate PR for that, and you can merge one or the other.

It's Ok to trigger a dagrun with a state of 'queued', run_type=manual just like we do in the UI. I think we should work on it instead of what you have in the other PR. WDYT?

[potiuk]

Agree with @ephraimbuddy - we should not trigger "any" state and #30149 seems to handle it better.

[SamWheating]

It's Ok to trigger a dagrun with a state of 'queued', run_type=manual just like we do in the UI. I think we should work on it instead of what you have in the other PR. WDYT?

I don't really see the point of having a field with only one acceptable value in the POST body, in this case I think it makes more sense to use a default value and mark it as read-only. Thoughts?

[potiuk]

I don't really see the point of having a field with only one acceptable value in the POST body, in this case I think it makes more sense to use a default value and mark it as read-only. Thoughts?

Yes. With the exception of backwards compatibility. If removal of the state would cause previous requests to fail (Even wit t state "queued", then we should not remove it just make it optional and raise deprecation warning in case someone passes it..

[SamWheating]

Yes. With the exception of backwards compatibility. If removal of the state would cause previous requests to fail (Even wit t state "queued", then we should not remove it just make it optional and raise deprecation warning in case someone passes it..

Agreed, but in this case requests which set the state field would previously fail with a 400, see example curl in the initial issue (#30075), so I think all we need to do here is fix up the spec + documents as per #30149

[potiuk]

Yes. With the exception of backwards compatibility. If removal of the state would cause previous requests to fail (Even wit t state "queued", then we should not remove it just make it optional and raise deprecation warning in case someone passes it..

Agreed, but in this case requests which set the state field would previously fail with a 400, see example curl in the initial issue (#30075), so I think all we need to do here is fix up the spec + documents as per #30149

Ah. I see. yeah. Then it makes sense to remove it - it's not "API change" it's a bugfix.

[potiuk]

Classic: