Proposal: Add ResultStatus.Accepted to support asynchronous processing (HTTP 202)
- Dominant language
- C#
- Stars
- 1k
- Forks
- 127
- PR merge metrics
- No merged PRs in 30d
Description
Hi 👋
I'd like to suggest adding a new `ResultStatus.Accepted `to the Ardalis.Result enum.
📌 Use Case
In some of my APIs, I'm following an asynchronous processing model. For example:
- A command is received via HTTP,
- It's validated and enqueued for background processing (e.g., via a message bus),
- The server immediately returns a 202 Accepted to indicate the request was valid, but the processing is still ongoing.
Currently, the closest statuses (Ok, Created, etc.) don't accurately reflect this "accepted but not completed" state.
✅ Why add Accepted?
This status maps directly to HTTP 202 semantics:
"The request has been accepted for processing, but the processing has not been completed."
Adding it to ResultStatus would allow consumers to explicitly represent this case using the library.
💡 Suggested addition
```
public enum ResultStatus
{
Ok,
Created,
Accepted, // ← Add this
Error,
Forbidden,
Unauthorized,
Invalid,
NotFound,
NoContent,
Conflict,
CriticalError,
Unavailable
}
```
Thanks for the great work on Ardalis.Result.
Best regards,
Jordi
Contributor guide
Research direction
Start at the ResultStatus enum and trace where its values are converted to HTTP response codes. Check the related tests or response-mapping entry points, then confirm that Accepted consistently produces HTTP 202 and is covered by tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- api, backend-api-design
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100