It seems we raise the same locking exception in TaskflowAPI.run_flow() regardless whether the lock is active or if there's an unexpected problem, such as the Redis server being misconfigured or unavailable.
This is a problem because in e.g. ZoneSubmitMoveAPIView, we should return a different status based on what type of locking exception was encountered. The response should be 503 if the project is simply locked, or 500 if e.g. a Redis error occurs. Right now, we return APIException with the status of 500 in any case.
As this is a slightly breaking change for the REST API, I'm tentatively setting this for the v1.0 milestone.
It seems we raise the same locking exception in
TaskflowAPI.run_flow()
regardless whether the lock is active or if there's an unexpected problem, such as the Redis server being misconfigured or unavailable.This is a problem because in e.g.
ZoneSubmitMoveAPIView
, we should return a different status based on what type of locking exception was encountered. The response should be503
if the project is simply locked, or500
if e.g. a Redis error occurs. Right now, we returnAPIException
with the status of500
in any case.As this is a slightly breaking change for the REST API, I'm tentatively setting this for the v1.0 milestone.
This is related to #1842 and #1844.