Skip to content

Conversation

@rstam
Copy link
Contributor

@rstam rstam commented May 27, 2025

No description provided.

@rstam rstam requested review from adelinowona and sanych-sun May 27, 2025 18:33
@rstam rstam added bug Fixes issues or unintended behavior. improvement Optimizations or refactoring (no new features or fixes). labels May 27, 2025
@rstam rstam changed the title CSHARP-5572: Implement new KnownSerializerFinder. CSHARP-5572: Implement new KnownSerializerFinder May 27, 2025
@Szmiglo
Copy link

Szmiglo commented Jul 23, 2025

hi @rstam, what's the status of this effort?

@rstam
Copy link
Contributor Author

rstam commented Jul 23, 2025

hi @rstam, what's the status of this effort?

It is progressing well, but it is a large effort. I work on this whenever I'm not working on some smaller higher priority task.

@rstam rstam requested review from a team and removed request for a team August 21, 2025 15:25
@rstam rstam force-pushed the csharp5572 branch 2 times, most recently from 86fbb24 to 56a464c Compare October 13, 2025 15:15
}
}

if (_map.TryGetValue(node, out var existingSerializer))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should move the duplicate check to the beginning of the AddSerializer method to implement fail-fast behavior. This would avoid unnecessary serializer transformation work when a serializer already exists for the node.

However, I notice the current implementation places this check at the end, likely to preserve information about the conflicting serializer for the exception. While this debugging information could be helpful, I question just how useful it is. Knowing where a duplicate attempt happened seems more useful knowing what the conflicting serializer would have been.

I lean toward the fail-fast approach since the conflicting serializer details seem like a "nice-to-have" rather than essential debugging information.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we move the error check further up then we have to remove information about the redundant serializer from the error message.

Also, I don't think we need to worry about failing fast because we actually never expect to hit this error. This check is here to help us find bugs. In the absence of bugs this exception will never be thrown.

private bool _isMakingProgress = true;
private readonly KnownSerializerMap _knownSerializers;
private int _oldKnownSerializersCount = 0;
private int _pass = 0;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like this is never used?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed.

var newKnownSerializersCount = _knownSerializers.Count;
if (newKnownSerializersCount == _oldKnownSerializersCount)
{
if (_useDefaultSerializerForConstants)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we maybe make use of a state enum as such:

private enum DiscoveryPhase
{
    InferringFromContext,      // Not using defaults
    UsingDefaultSerializers,   // Last attempt with defaults
    Complete                    // No more progress possible
}

to replace the use of all these booleans used in keeping track of the state of the visitor?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's somewhat reasonable, but I think the booleans work better here.

There are only 2 booleans.

One issue is that if we ever had more states the order of the enum values could get very confusing and maybe even no order is possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Fixes issues or unintended behavior. improvement Optimizations or refactoring (no new features or fixes).

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants