Description:
Building upon the proposal to use separate Hangfire queues per flow type, we've further refined the concept to provide even more flexibility and convenience. In scenarios where users do not specify a queue using the proposed QueueAttribute, we suggest implementing a default behavior. Specifically, when no QueueAttribute is applied to a flow class, the name of the class itself will be used as the Hangfire queue name.

Feature Details:

• Default Queue Behavior: If a flow class is not adorned with the QueueAttribute, the name of the class will be utilized as the Hangfire queue name.

• Use Cases:

  • Prioritization: By using the class name as the queue name, users can implicitly prioritize certain flows by manipulating the order of class names.
  • Logical Grouping: Flows that are not assigned a specific queue can still be logically grouped based on their class names.
  • Simplified Configuration: Users can leverage this behavior without explicitly applying the QueueAttribute, simplifying the configuration process.

• Example:
  If a flow class named CriticalFlow is not attributed with QueueAttribute, the default queue name for this flow will be CriticalFlow.

• Implementation:

  • Modify the MapFlow method to automatically determine the Hangfire queue name based on the class name if no QueueAttribute is applied.
  • Ensure that this behavior aligns with the broader goal of improving job queue management.

• Benefits:

  • Streamlined Configuration: Users who do not need to explicitly set queue names can rely on the default behavior without additional steps.
  • Logical Grouping: Even without attribute configuration, flows can still be logically grouped by queue based on their class names.
  • Compatibility: This behavior complements both attributed and non-attributed flows, providing a unified approach.

Your feedback on this refined enhancement proposal is greatly appreciated. Please share your thoughts and considerations regarding the suggested default behavior. If there are any potential concerns or considerations that should be addressed during implementation, kindly let us know. Your input will play a crucial role in shaping this feature for the benefit of AsyncFlow library users.

Is this something that seems feasible and you'd be interested in? Some of our software is still on .NET Framework and your library looks like it would be incredibly helpful! I'd be happy to open a PR for this if so!

Title:

Support for CancellationToken in IAsyncFlow

Description:

Problem:

Currently, our IAsyncFlow interface does not support CancellationToken. This means that if a delete request comes in while ProcessAsync is still running, the process won't be cancelled immediately.

Detailed Explanation:

When processing long-running jobs, it's crucial to have the ability to cancel them if needed. Not having cancellation support can lead to wasted resources, especially if the result of the job is no longer required (e.g., if a delete request has been received).

Proposed Solution:

Introduce a CancellationToken parameter to the ProcessAsync method in the IAsyncFlow interface. This would enable any implementing class to respect cancellation requests.

Task<TResult> ProcessAsync(TRequest request, CancellationToken cancellationToken);

Additionally, when handling the Delete request on the API side, signal the cancellation token to attempt to halt the ongoing operation.

Impact:

Existing implementations of the IAsyncFlow interface would need to be updated to handle the new parameter. Documentation would need to be updated as well to guide users on how to use the cancellation token properly.

New Endpoint Proposal: Fetching Job Errors

Issue Type: Feature Request

Description:
As we continue to evolve the AsyncFlow library, it's become apparent that there's a potential gap in our error-handling capabilities. Currently, while users can track the status of their jobs, there isn't a straightforward way to fetch detailed error information in case a job fails. This can be invaluable for both developers and end-users to understand what might have gone wrong.

Proposal:
Introduce a new endpoint:
/{flowName}/{jobId}/error

This endpoint will return detailed error information if the corresponding job encounters a failure.

Response Structure (proposed):

{
    "JobId": "unique-job-id",
    "Error": {
        "Type": "ExceptionType",
        "Message": "Detailed error message",
        "StackTrace": "Stack trace details..."
    }
}

Customization:
In line with the ethos of flexibility that AsyncFlow offers, we should also provide users with the ability to customize the error response. This can be achieved by incorporating a Func<Exception, IResult> within the AsyncFlowEndpointConfigurator, allowing users to modify the default error output or even introduce additional logging mechanisms.

Benefits:

• Provides clearer insights into job failures.
• Enhances user experience by offering detailed feedback.
• Allows users to tailor error outputs, making it adaptable for various applications.

Implementation Steps (tentative):

1. Design the endpoint structure.
2. Integrate it with the job execution flow to capture and relay errors.
3. Implement the customization mechanism through AsyncFlowEndpointConfigurator.
4. Update documentation and provide examples.

Title:

Introduce IProgress Support in IAsyncFlow

Description:

Problem:

For long-running tasks executed by IAsyncFlow, there's currently no mechanism to report and track progress during the ProcessAsync method execution. This means users can't gauge how much of the job has been completed and might be left waiting without any indication of progress.

Detailed Explanation:

To provide users with more feedback on the progress of their jobs, we should introduce support for progress reporting within the IAsyncFlow interface. This will allow the job to provide periodic updates about how much of the task has been accomplished.

Proposed Solution:

1. Modify the IAsyncFlow interface to include an IProgress<ProgressData> parameter for the ProcessAsync method.

Task<TResult> ProcessAsync(TRequest request, IProgress<ProgressData> progress, CancellationToken cancellationToken);

2. The ProgressData should be defined as:

public record ProgressData(string Progress, double Value);

3. In the API, when the status call is made for a job, the latest progress data should be returned along with the current job status.

Impact:

This enhancement will improve user experience by providing real-time feedback on job progress. Existing implementations of IAsyncFlow will need to be updated to cater to the new parameter. Additionally, we'll need to store progress data for each job, which might require changes to our storage mechanism.

Usage scenario: For example, I have a time-consuming upload file parsing operation, and then support the upload file operation using form-data form