Skip to content
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

Does the LogPropertyIgnoreAttribute work with Record Types? #5339

Open
everettcomstock opened this issue Aug 5, 2024 · 4 comments
Open

Does the LogPropertyIgnoreAttribute work with Record Types? #5339

everettcomstock opened this issue Aug 5, 2024 · 4 comments
Assignees
Labels
area-compliance waiting-author-feedback 📭 The author of this issue needs to respond in order for us to continue investigating this issue.

Comments

@everettcomstock
Copy link

everettcomstock commented Aug 5, 2024

I recently implemented the use LogPropertiesAttributes in a solution that uses a mix of classes and record Types. The attribute behavior seems to work correctly when setting the Transitive value to true. The objects properties, and the properties of records within the object are properly logged.

However, when the object being logged has a property that is a record Type, the LogPropertyIgnoreAttribute does not seem to work (the property values are still logged)? After changing the child property from a Record Type to a Class, the LogPropertyIgnoreAttribute works properly, and the property values are no longer logged.

Could this actually have nothing to do with the LogPropertyIgnoreAttribute and instead be an issue with the LogPropertiesAttribute Transitive feature? I notice that the remarks say this:

When logging the properties of an object, this property controls the behavior for each encountered property. When this property is false, then each property is serialized by calling object.ToString() to generate a string for the property. When this property is true, then each property of any complex objects are expanded individually.

Does the experimental Transitive feature currently only work with objects?

Thanks!

@dariusclay
Copy link
Contributor

Can you share a simplified example so we can investigate? Where are you putting LogPropertyIgnore exactly?

@dariusclay
Copy link
Contributor

dariusclay commented Sep 19, 2024

For example, this behaves as expected:

public static partial class LogPropertyIgnoreTests
{
    [LoggerMessage(0, LogLevel.Error, "LogTestObject")]
    public static partial void LogTestObject(ILogger logger, [LogProperties] LogPropertyIgnoreTestObject testObject);
}

public class LogPropertyIgnoreTestObject
{
    [LogProperties]
    public LogPropertyIgnoreTestClass TestClass { get; set; } = new();

    [LogProperties]
    public LogPropertyIgnoreTestRecord TestRecord { get; set; } = new("A", "B");
}

public class LogPropertyIgnoreTestClass
{
    [LogPropertyIgnore]
    public string Property1 { get; set; } = "A"; // doesn't get logged

    public string Property2 { get; set; } = "B";
}

public record LogPropertyIgnoreTestRecord(string Property1, string Property2)
{
    [LogPropertyIgnore]
    public string Property3 { get; set; } = "C"; // doesn't get logged
}

@dariusclay
Copy link
Contributor

As far as when Transitive=True, I need to check the logic more and see if it was intended to work together with LogPropertyIgnore (which I assume it should). As of now I cannot get it to work with either classes or records when it's specified at the top-level (in the log method). @geeknoid

@geeknoid
Copy link
Member

There are some issues with how attributes are propagated in record definitions, which may affect the behavior here. But having a full example of the problem would let us assess whether this is what is happening here.

@RussKie RussKie added waiting-author-feedback 📭 The author of this issue needs to respond in order for us to continue investigating this issue. and removed untriaged labels Sep 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-compliance waiting-author-feedback 📭 The author of this issue needs to respond in order for us to continue investigating this issue.
Projects
None yet
Development

No branches or pull requests

4 participants