-
Notifications
You must be signed in to change notification settings - Fork 2
Feedback #39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Feedback #39
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR introduces comprehensive feedback improvements to the ManagedCode.Communication library, focusing on enhanced logging capabilities, command idempotency features, improved JSON serialization, and modernized API design.
- Updates .NET target framework from multiple versions (6.0, 7.0, 8.0) to .NET 9.0 exclusively
- Introduces high-performance logging with source generators and centralized logger configuration
- Implements comprehensive command idempotency system with memory and Orleans store implementations
Reviewed Changes
Copilot reviewed 40 out of 40 changed files in this pull request and generated 7 comments.
Show a summary per file
File | Description |
---|---|
README.md | Updates .NET version badge and adds logging configuration documentation |
ManagedCode.Communication/ResultT/Result.cs | Adds JSON serialization attributes and new validation properties |
ManagedCode.Communication/Result/Result.cs | Adds IsValid property and InvalidObject for JSON serialization |
ManagedCode.Communication.csproj | Adds Microsoft.Extensions.Caching.Memory dependency for command features |
ManagedCode.Communication/Logging/* | Introduces high-performance logging with source generators |
ManagedCode.Communication/Commands/* | Implements comprehensive command idempotency system |
ManagedCode.Communication/IResult*.cs | Enhances interfaces with JSON attributes and validation properties |
ManagedCode.Communication.AspNetCore/* | Modernizes service registration and filter configuration |
ManagedCode.Communication.Orleans/* | Updates Orleans store with new idempotency interface methods |
Test files | Comprehensive test coverage for new features |
Comments suppressed due to low confidence (1)
ManagedCode.Communication/Commands/Extensions/CommandIdempotencyExtensions.cs:140
- The magic numbers 0.8 and 0.4 for jitter calculation should be extracted as named constants to improve code readability and maintainability.
this ICommandIdempotencyStore store,
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
_lastResortLoggerFactory ??= LoggerFactory.Create(builder => | ||
builder.SetMinimumLevel(LogLevel.Warning)); | ||
|
||
return new Logger<Result>(_lastResortLoggerFactory); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Creating a new LoggerFactory with every call when _lastResortLoggerFactory is null could be inefficient. Consider using a singleton pattern or lazy initialization to ensure the factory is created only once.
return new Logger<Result>(_lastResortLoggerFactory); | |
// Use thread-safe lazy initialization for the last resort logger factory | |
return new Logger<Result>(_lastResortLoggerFactory.Value); |
Copilot uses AI. Check for mistakes.
ManagedCode.Communication/Commands/Stores/MemoryCacheCommandIdempotencyStore.cs
Show resolved
Hide resolved
ManagedCode.Communication/Commands/Stores/MemoryCacheCommandIdempotencyStore.cs
Show resolved
Hide resolved
# Conflicts: # ManagedCode.Communication/ResultT/Result.cs
@nandos13 what do you think about this one? I want to add interface to sstandartize all method like From and etc, to do not forgot to implement them. |
@KSemenenko It would be great to leverage static interface members here. Again, this could really reduce duplicated code and make it much easier to add new overloads. I mocked up the idea below: public interface IResultFactory<TSelf>
where TSelf : IResultFactory<TSelf>
{
// Contract only requires these two methods to be implemented by the type
static abstract TSelf Succeed();
static abstract TSelf Fail(Problem problem);
// Everything else can be implemented on the interface, since they are the same for all types.
// Eg. This method creates a generic error Problem instance,
// then pass it along to the abstract Fail method above.
static TSelf Fail()
{
var problem = Problem.GenericError();
return TSelf.Fail(problem);
}
} Now, the public partial struct Result : IResultFactory<Result>
{
public static Result Succeed()
{
return CreateSuccess();
}
public static Result Fail(Problem problem)
{
return CreateFailed(problem);
}
} and the rest of the specific overloads (eg. |
Thanks for feedback @nandos13 |
…empotencyStore.cs Co-authored-by: Copilot <[email protected]>
Description
Type of Change
Changes Made
Testing
Checklist
Related Issues
Closes #
Screenshots (if applicable)
Additional Notes