Introduce the `ReCClientOptions` class in the new `ReC.Client`
namespace. This class includes the `LogSuccessfulRequests`
property, which allows users to enable or disable logging for
successful API requests via the injected `ILogger`. Failed
requests are unaffected and will always throw `ReCApiException`.
The property defaults to `true`. XML documentation is included
to describe the class and its behavior.
Refactored the `EnsureSuccessAsync` method to `HandleResponseAsync`
and added optional `ILogger` support for logging HTTP request
and response details.
- Added `using Microsoft.Extensions.Logging;` for logging.
- Log success responses with HTTP method, URI, status code,
and reason phrase.
- Updated exception message construction for clarity.
- Added conditional compilation for nullable `ILogger?`
in non-NET Framework targets.
- Improved code maintainability by consolidating logic.
Introduced optional ILogger support across BaseCrudApi and its
derived classes to enable logging of API call outcomes. Updated
constructors to accept an optional ILogger parameter, with
conditional compilation for .NET Framework compatibility.
Replaced EnsureSuccessAsync with HandleResponseAsync in CRUD
methods to integrate logging. Updated derived API classes
(CommonApi, EndpointAuthApi, EndpointParamsApi, EndpointsApi,
ProfileApi, RecActionApi, ResultApi) to pass ILogger to the base
class.
Added Microsoft.Extensions.Logging imports and ensured backward
compatibility by making ILogger optional and handling nullable
reference types in non-.NET Framework environments.
Updated the `ReCClient` constructor to include an optional `ILogger` parameter for logging API call outcomes. Added support for both .NET Framework and other frameworks by using non-generic and generic `ILogger` types, respectively. Updated API-related objects (`RecActionApi`, `ResultApi`, etc.) to accept and utilize the `ILogger` instance for enhanced logging functionality.
The return type of the `InvokeAsync` method has been changed from `Task<bool>` to `Task` for both overloads, removing the boolean return value for success indication.
The `<returns>` XML documentation tag has been removed, and a new `<exception>` tag has been added to document the potential `ReCApiException` thrown when the API responds with a non-success status code.
The implementation now uses `ReCClientHelpers.EnsureSuccessAsync` to handle API responses, replacing the previous `resp.IsSuccessStatusCode` check.
These changes improve clarity and align the method's behavior with standard practices for handling asynchronous operations and exceptions.
Updated `CreateAsync`, `UpdateAsync`, and `DeleteAsync` methods to return `Task` instead of `Task<bool>`. Removed `<returns>` documentation and added `<exception>` tags to indicate that a `ReCApiException` is thrown for non-successful API responses. Replaced `resp.IsSuccessStatusCode` checks with `ReCClientHelpers.EnsureSuccessAsync` to enforce exception-based error handling. These changes align with modern asynchronous error-handling practices.
Introduced the `EnsureSuccessAsync` method in `ReCClientHelpers.cs` to handle HTTP response validation asynchronously. This method throws a `ReCApiException` for non-success status codes, including detailed error information such as status code, reason phrase, HTTP method, URI, and response body (if available).
Updated `using` directives to support asynchronous operations and cancellation tokens. Removed redundant `#if NETFRAMEWORK` directive around `using System.Net.Http;` and adjusted `using System.Net.Http.Json;` placement for consistency.
Added exception handling for response body read failures to ensure status information is still propagated. Enhanced error reporting for failed HTTP requests.
A new `ReCApiException` class was introduced in the `ReC.Client` namespace to represent errors returned by the ReC API.
The class includes properties for detailed error information:
- `StatusCode`, `ReasonPhrase`, `ResponseBody`, `Method`, and `RequestUri`.
A constructor was added to initialize these properties. Conditional compilation directives ensure compatibility between .NET Framework and other .NET targets. The class is marked as `[Serializable]` for non-.NET Framework targets.
Updated the `InvokeAsync` method in the `ReC.Client.Api` namespace to use `using` statements for the `content` and `resp` objects. This change ensures proper disposal of these resources, improving memory management and preventing potential leaks. The functional behavior of the method remains unchanged.
Updated `CreateAsync<T>`, `UpdateAsync<T>`, and `DeleteAsync<T>`
methods to return a `bool` indicating success instead of
`HttpResponseMessage`. Added `using` statements to ensure proper
disposal of HTTP content and response objects. Simplified the
interface for better usability by leveraging `IsSuccessStatusCode`
to determine operation success.
Updated the project version, assembly version, file version, and informational version from 2.3.0-beta to 2.4.0-beta in the ReC.API.csproj file. This prepares the project for the next beta release.
Add AutoDetectHeaders option to RecAction config and handler. When enabled, automatically set Content-Type based on body content (JSON or XML) and default Accept to application/json if missing. Log warnings when headers are auto-detected. Improves robustness and makes header detection configurable.
EnableSensitiveDataLogging and EnableDetailedErrors are now configurable via appsettings.json under the "EfCore" section. Program.cs reads these values from configuration instead of hardcoding them, allowing runtime control of EF Core logging and error detail behavior.
Enhance InvokeRecActionViewCommandHandler to robustly handle invalid or non-strict HTTP header values. "Content-Type" and "Authorization" headers are now set using strict parsing with fallback to TryAddWithoutValidation on failure, logging warnings for easier debugging. General headers and API key headers also use this strict-then-fallback approach, making HTTP request construction more tolerant of malformed values and reducing runtime errors.
Inject optional ILogger into InvokeRecActionViewCommandHandler for enhanced logging. When adding HTTP headers, catch FormatException and log a warning with relevant context, then fall back to TryAddWithoutValidation. This increases robustness and observability for malformed or non-standard headers.
Wrap ExecuteScalarAsync in try-catch blocks in BodyQueryBehavior and HeaderQueryBehavior. Throw DataIntegrityException with detailed context if SQL execution fails, aiding in diagnosing malformed or problematic stored SQL queries.
Throw DataIntegrityException when body or header queries return
null, no result, or invalid JSON. Remove ILogger and related
logging from HeaderQueryBehavior for simplification. This change
ensures data integrity issues are surfaced immediately.
Refactored BodyQueryBehavior and HeaderQueryBehavior to operate on collections of RecActionViewDto instead of single instances. Moved SQL execution and property assignment logic into private helper methods using ADO.NET commands. Improved null checks and logging, and updated type constraints to reflect the new usage. Behaviors now return the modified collection after processing.
Replaced string-based entity identifiers in CRUD procedure and command classes with a strongly-typed EntityType enum. Updated all relevant handlers and records to use the new enum property, improving type safety and maintainability. Added necessary using directives and updated documentation comments to reflect these changes.
Refactored DeleteObjectProcedureValidator, InsertObjectProcedureValidator, and UpdateObjectProcedureValidator to use .IsInEnum() for validating the Entity property. This replaces custom or hardcoded checks with enum-based validation, improving consistency, maintainability, and robustness across all validators.
Introduced the EntityType enum to represent target entities for stored procedure operations, along with XML documentation and mapping comments. Added EntityTypeExtensions with a ToDbString method for consistent DB string conversion. Updated StoredProcedureBuilder to support adding EntityType parameters, improving type safety and maintainability. Minor formatting and using directive adjustments included.
Deleted FakeRequest.cs and ResultType.cs, removing the FakeRequest class (with Body and Header properties) and the ResultType enum (Full, OnlyHeader, OnlyBody). These types are no longer needed in the codebase.
Introduced UpdateObjectProcedureValidator using FluentValidation to enforce constraints on UpdateObjectProcedure fields, including ID checks and maximum length restrictions on various properties and nested objects.
Introduced ReadResultViewQueryValidator to enforce that at least one filter (Id, ActionId, ProfileId, or BatchId) is provided. Also validates that numeric IDs are greater than 0 and BatchId is not empty when present.
Introduced ReadRecActionViewQueryValidator using FluentValidation to ensure ProfileId, if provided, is greater than 0. Returns a specific validation message if the rule is violated.
Introduced ReadProfileViewQueryValidator using FluentValidation to ensure the Id property, if provided, is greater than 0. Includes a custom error message for invalid Id values.
Introduce InsertResultCommandValidator using FluentValidation to enforce required and value constraints on ActionId and References.BatchId properties, including custom error messages.
Introduced DeleteObjectProcedureValidator using FluentValidation to ensure Start is greater than 0 and End is greater than or equal to Start, with custom error messages for each rule.
Refactored InvokeBatchDuplicateGuardTests to expect and assert
FluentValidation's ValidationException instead of the custom
BadRequestException when a duplicate BatchId is submitted.
Assertions and comments were updated accordingly, and the
DigitalData.Core.Exceptions import was removed. Test logic
remains unchanged.
Removed the check that blocked rec action invocation if results
already existed for a batch. Also updated using directives for
exception handling and logging.
Introduced InvokeBatchRecActionViewsCommandValidator using FluentValidation. This validator ensures BatchId is provided and checks asynchronously via MediatR that no results exist for the given BatchId before allowing the command to proceed. Provides a clear validation message if results are already present.
Removed the count of existing results from the BadRequestException
message when invoking rec actions for a batch. The error now simply
states that results are already associated with the batch.
Updated project version fields in ReC.API.csproj from 2.1.0-beta to 2.2.0-beta, including Version, AssemblyVersion, FileVersion, and InformationalVersion.
Changed DesktopBuildPackageLocation in IISProfile.pubxml to output the build package to the M:\App&Service directory instead of the P: drive. This ensures published packages are stored in the new target location.
Replaced Last with LastBatch in ReadResultViewQuery to enable fetching all results from the most recent batch. Updated handler logic and tests accordingly, and added GetLastBatchEntitiesAsync to retrieve entities by latest BatchId.
Added InvokeBatchDuplicateGuardTests to verify that invoking batch rec actions with an existing BatchId throws BadRequestException, while using a new BatchId does not trigger the duplicate guard. Tests use MediatR ISender and real database data for integration coverage. Added necessary using directives.
Add validation in InvokeRecActionViewsCommandHandler to check
for existing results before invoking rec actions for a batch.
Throw BadRequestException if results are found to avoid
duplicate processing. Add necessary using statements for
exceptions and queries.
Added an optional BatchId property to ReadResultViewQuery to enable filtering by BatchId. Updated ReadResultViewQueryHandler to apply this filter when BatchId is provided. Also adjusted the order of IncludeAction logic for clarity.
Introduced AnyResultViewQuery and its handler to determine if any ResultView entity exists matching optional filters (Id, ActionId, ProfileId, BatchId). The handler builds the query dynamically and uses AnyAsync for efficient existence checks.
Enforce non-nullable References in RecActionController and InvokeBatchRecActionViewsCommand. Update tests to always provide References and add missing using directive. Improves type safety and ensures consistent reference handling.
Added BatchId and AddedWho properties to ResultViewDto. Changed BatchId in ResultView from required to nullable to align with DTO and support optional batch IDs.
Changed the BatchId property in the ResultView class from a nullable string to a required non-nullable string. This ensures that BatchId must always be provided when creating a ResultView instance, improving data integrity.
Changed the References property in InsertResultCommand from a nullable type to required. References must now always be provided and cannot be null when creating an InsertResultCommand instance. This enforces stricter data integrity for command creation.
Replaced all usages of InvokeReferencesDto with InvokeReferences across controllers, commands, and DTOs. This change standardizes the reference type naming by removing the "Dto" suffix, with no changes to the structure or behavior.
Updated InvokeRecActionViewCommand and InvokeReferencesDto to require non-null References and BatchId. Updated RecActionApi.InvokeAsync to require InvokeReferences and added an overload accepting batchId for convenience. This enforces stricter input validation and aligns client and backend requirements.
Reduced the underlying type of the RecStatus enum from short to byte to decrease memory usage. No changes were made to the enum values or their definitions.
Changed the Info property from short? to short in InsertResultCommand,
making it a required field and ensuring it cannot be null. This enforces
that all InsertResultCommand instances must provide a value for Info.
Changed SQL parameter type for pRESULT_STATUS_ID from SmallInt to TinyInt in both InsertObjectProcedureHandler and UpdateObjectProcedureHandler to align with database schema and ensure type consistency.
