feat: allow custom HTTP status codes when using DiscardTaskException #54
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![codeclimate[bot]](https://avatars.githubusercontent.com/in/9403?s=60&v=4){kind=small}
rodrigoalmeidaee
force-pushed
the
feature/custom-discard
branch
from
aa065bf
to
1f791c8
Compare
joaodaher
previously approved these changes
Aug 6, 2024
rodrigoalmeidaee
force-pushed
the
feature/custom-discard
branch
from
1f791c8
to
b8f2868
Compare
To prevent a Google Cloud Task from being retried, it is necessary to return a status code in the 200-299 range. The mechanism django_cloud_tasks currently offers for this is raising `DiscardTaskException`, but in this case the status code will always be HTTP 202 (Accepted). When we want to discard a task due to an unrecoverable error, this HTTP status code offers no good semantics. Also, from a monitoring perspective, simply discarding a task (perhaps it is no longer needed - for example: attempting to delete something that has already been deleted) and discarding a task due to an unrecoverable error (for example: the task input is invalid) are two different things, but we have no means to differentiate them if the status code is always the same. This PR adds a bit of flexibility, allowing DiscardTaskException to receive an HTTP status code / HTTP status reason phrase as either constructor arguments, or by subclassing it and overriding default_http_status_code / default_http_status_reason. This PR won't add a built-in "UnrecoverableTaskException" base class because there is no HTTP 2xx status code (even when considering augmented standards) to reflect this scenario, so we will leave it up to each project that uses django-cloud-tasks to configure this setup, as it will be project-specific by definition.
rodrigoalmeidaee
force-pushed
the
feature/custom-discard
branch
from
b8f2868
to
8aee32f
Compare
|
Code Climate has analyzed commit 8aee32f and detected 0 issues on this pull request. View more on Code Climate. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
To prevent a Google Cloud Task from being retried, it is necessary to return a status code in the 200-299 range. The mechanism django_cloud_tasks currently offers for this is raising
DiscardTaskException, but in this case the status code will always be HTTP 202 (Accepted). When we want to discard a task due to an unrecoverable error, this HTTP status code offers no good semantics. Also, from a monitoring perspective, simply discarding a task (perhaps it is no longer needed - for example: attempting to delete something that has already been deleted) and discarding a task due to an unrecoverable error (for example: the task input is invalid) are two different things, but we have no means to differentiate them if the status code is always the same.This PR adds a bit of flexibility, allowing DiscardTaskException to receive an HTTP status code / HTTP status reason phrase as either constructor arguments, or by subclassing it and overriding default_http_status_code / default_http_status_reason.
This PR won't add a built-in "UnrecoverableTaskException" base class because there is no HTTP 2xx status code (even when considering augmented standards) to reflect this scenario, so we will leave it up to each project that uses django-cloud-tasks to configure this setup, as it will be project-specific by definition.