CSHARP-5442: Atlas Search doesn't respect the correct serializer #1583

papafe · 2024-12-31T14:56:55Z

papafe · 2024-12-31T15:45:03Z

@BorisDog I've added you as a reviewer since it seems you were the one that worked on search, mostly. This is still a work in progress, I've broke some things in the process.
A couple of notes:

Probably we need to change the in and range search definitions as well to use the correct serializers.
This is effectively a behaviour breaking change, so we need to decide if we want include it in next version or wait for next major

papafe · 2025-01-02T11:20:23Z

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

+
+                var renderedField = _arrayField.Render(args);
+
+                var serializer =


Incredibly ugly, but was just testing if it worked

@rstam this is what I was referring to.
Do you think it would be worth adding a new property to RenderArgs so that we can get directly the serializer we need (similar to RenderForElemMatch for instance)?

I think this is on the right track but can use a little tweaking to how the right serializer is found and to reduce duplication between how scalar and array fields are handled.

Something like this:

private protected override BsonDocument RenderArguments(RenderArgs<TDocument> args) { IBsonSerializer<TValue> valueSerializer; if (_field != null) { var renderedField = _field.Render(args); valueSerializer = renderedField.FieldSerializer; } else { var renderedArrayField = _arrayField.Render(args); valueSerializer = (IBsonSerializer<TValue>)ArraySerializerHelper.GetItemSerializer(renderedArrayField.FieldSerializer); } var document = new BsonDocument(); using var bsonWriter = new BsonDocumentWriter(document); var context = BsonSerializationContext.CreateRoot(bsonWriter); bsonWriter.WriteStartDocument(); bsonWriter.WriteName("value"); valueSerializer.Serialize(context, _value); bsonWriter.WriteEndDocument(); return document; }

Perfect, this solves my doubts. That makes sense, I was mostly focusing on how to get the correct serializer before trying to refactor.

Regarding IBsonArraySerializer, the majority of times when we implement that interface we also implement IChildSerializerConfigurable, and that makes sense. It also seems that for this use case the result we'd get would be the same, so what would you think about using IChildSerializerConfigurable instead?
To be honest this is more of a generic question, I'm curious about if there's any preference on using one over the other, of course considering that TryGetItemSerializationInfo can potentially return more info (not in this case though).

IBsonArraySerializer and IChildSerializerConfigurable are orthogonal. We can't just implement IChildSerializerConfigurable instead of IBsonArraySerializer.

In this case we must implement IBsonArraySerializer.

It is true that in general whenever implementing IBsonArraySerializer we would likely also want to implement IChildSerializerConfigurable. However, that applies mostly to public serializers that a user might want to configure. This is an internal serializer, so I think implementing IBsonArraySerializer is sufficient.

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

rstam · 2025-01-03T20:36:55Z

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

+        public EqualsSearchDefinition(FieldDefinition<TDocument, TField> path, TField value, SearchScoreDefinition<TDocument> score)
+            : base(OperatorType.Equals, new SingleSearchPathDefinition<TDocument>(path), score)
+        {
+            ValidateType();


I question whether we need to have ValidateType at all. Looks to me like this was just a client-side limitation related to what .NET types ToBsonValue knew how to convert to BSON, but now that we are using the proper serializer this limitation should no longer exist.

I checked with Boris and he confirmed that it is a server limitation which types are supported.

But even so, we probably shouldn't be checking this client side. We should just send the value to the server and let it return an error if it doesn't support the data type.

That way our driver will work well with all supported versions of the server, which might have different limitations. And if future server versions support new value types we won't have to make any changes.

I also like this idea. I tried to keep it consistent with what was there before, but I agree that moving this check server side would allow us to be more free in what we do and don't support over time.
I need to remember to do the same with the other operators too.

rstam · 2025-01-03T20:38:34Z

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

+
+                var renderedField = _arrayField.Render(args);
+
+                var serializer =


I think this is on the right track but can use a little tweaking to how the right serializer is found and to reduce duplication between how scalar and array fields are handled.

Something like this:

private protected override BsonDocument RenderArguments(RenderArgs<TDocument> args) { IBsonSerializer<TValue> valueSerializer; if (_field != null) { var renderedField = _field.Render(args); valueSerializer = renderedField.FieldSerializer; } else { var renderedArrayField = _arrayField.Render(args); valueSerializer = (IBsonSerializer<TValue>)ArraySerializerHelper.GetItemSerializer(renderedArrayField.FieldSerializer); } var document = new BsonDocument(); using var bsonWriter = new BsonDocumentWriter(document); var context = BsonSerializationContext.CreateRoot(bsonWriter); bsonWriter.WriteStartDocument(); bsonWriter.WriteName("value"); valueSerializer.Serialize(context, _value); bsonWriter.WriteEndDocument(); return document; }

rstam · 2025-01-03T20:40:16Z

src/MongoDB.Driver/FieldValueSerializerHelper.cs

@@ -317,6 +317,8 @@ internal class IEnumerableSerializer<TItem> : SerializerBase<IEnumerable<TItem>>
        {
            private readonly IBsonSerializer<TItem> _itemSerializer;

+            public IBsonSerializer<TItem> ItemSerializer => _itemSerializer;
+


Instead of adding this new public property have the class implement IBsonArraySerializer and implement the TryGetItemSerializationIinfo method:

public bool TryGetItemSerializationInfo(out BsonSerializationInfo serialization { serializationInfo = new(elementName: null, _itemSerializer, typeof(TItem)); return true; }

All serializers for array-like values should implement IBsonArraySerializer. I don't know why this class did not already implement it.

rstam · 2025-01-03T20:43:15Z

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

+                var renderedField = _arrayField.Render(args);
+
+                var serializer =
+                    (renderedField.ValueSerializer as FieldValueSerializerHelper.IEnumerableSerializer<TField>)


Instead of trying to cast to the very specific class FieldValueSerializerHelper.IEnumerableSerializer<TField> use the more general from (used everywhere else) to get the item serializer from an array-like serializer:

valueSerializer = (IBsonSerializer<TValue>)ArraySerializerHelper.GetItemSerializer(renderedArrayField.FieldSerializer);

This is why FieldValueSerializerHelper.IEnumerableSerializer<TItem> should implement IBsonArraySerializer (as all array-like serializers should). Not sure why it didn't already...

rstam · 2025-01-03T22:23:20Z

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

+        public EqualsSearchDefinition(FieldDefinition<TDocument, TField> path, TField value, SearchScoreDefinition<TDocument> score)
+            : base(OperatorType.Equals, new SingleSearchPathDefinition<TDocument>(path), score)
+        {
+            ValidateType();


I checked with Boris and he confirmed that it is a server limitation which types are supported.

But even so, we probably shouldn't be checking this client side. We should just send the value to the server and let it return an error if it doesn't support the data type.

That way our driver will work well with all supported versions of the server, which might have different limitations. And if future server versions support new value types we won't have to make any changes.

tests/MongoDB.Driver.Tests/Search/SearchDefinitionBuilderTests.cs

src/MongoDB.Driver/FieldValueSerializerHelper.cs

tests/MongoDB.Driver.Tests/Search/SearchDefinitionBuilderTests.cs

src/MongoDB.Driver/Search/SearchDefinition.cs

src/MongoDB.Driver/Search/SearchDefinitionBuilder.cs

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

src/MongoDB.Driver/FieldValueSerializerHelper.cs

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

tests/MongoDB.Driver.Tests/Search/SearchDefinitionBuilderTests.cs

rstam

I'm not too familiar with the Search API but as far as I can tell this looks OK.

You should get one more LGTM before merging to main though.

papafe · 2025-01-14T10:30:54Z

I'm not too familiar with the Search API but as far as I can tell this looks OK.

You should get one more LGTM before merging to main though.

@sanych-sun can you take a look too?

papafe · 2025-01-28T19:52:10Z

@BorisDog another thing to consider is that this is a behaviour breaking change, so we need to consider if we want to merge this now or wait. I think it could also be seen as a bug fix to be honest, but we should take a decision.
The difference is that now the correct registered serializers are used to serialize the values for the equals, in and range operators, while before default conversions were used, ignoring the registered serializers.

src/MongoDB.Driver/FieldValueSerializerHelper.cs

src/MongoDB.Driver/Search/SearchDefinition.cs

BorisDog · 2025-02-04T21:07:04Z

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

-            value switch
+        private protected override BsonDocument RenderArguments(RenderArgs<TDocument> args)
+        {
+            var searchPathDefinition = (SingleSearchPathDefinition<TDocument>)_path;


It's a bit inefficient that we need to render the path twice.
Also it would be good to extract this to a single helper method.

What do you and @rstam think about having new internal Render method in SearchPathDefinition, something like

(BsonValue, RenderedFieldDefinition) Render(...)

And passing field serializer in OperatorSearchDefinition.RenderArguments() ?

I see your point. I also think it's a little complicated to extract a method like that to SearchPathDefinition, since (BsonValue, RenderedFieldDefinition) Render(...) would make sense for a SingleSearchPathDefinition, but not for MultiSearchPathDefinition or WildcardSearchPathDefinition.
The issue here is that operators support various degrees of SearchPathDefinition. I'm trying to think of a more general solution that does not make breaking changes in the public API, but so far it all feels kinda clunky.

Yeah I meant that the returned RenderedFieldDefinition would be null in some cases. I agree that it's not the greatest design, but I don't have any better suggestion as of now. I does have the upside of not rendering the path twice.
As long as all the API changes are internal, we can evolve them in the future if we come up with a better idea (the new suggested Render method should be internal).

In 60c1d57, I've added a fix to avoid rendering the path twice. It's not super nice, and I'm not sure it's worth it given that probably the network call of the atlas search would be much greater than the time needed to render the path twice.

I think that if we want to have special cases depending on the path we could also specialize OperatorSearchDefinition.RenderArguments and produce a different method for each path type, for example OperatorSearchDefinition.RenderArgumentsForSingleSearchPath where we can pass additional arguments. This would require quite some changes, but could also allow to control which kind of path can be used with certain kinds of operators.

papafe · 2025-02-06T20:26:20Z

@BorisDog I've done some corrections following your suggestions, and it looks much better than before, thank you 😄
I'm a little bit unsure about the names though, they feel a little redundant

BorisDog · 2025-02-07T00:14:33Z

src/MongoDB.Driver/Search/SearchPathDefinition.cs

+
+        internal virtual (BsonValue, IBsonSerializer) RenderAndGetFieldSerializer(RenderArgs<TDocument> args) => (Render(args), null);
+
+        internal (string renderedPath, IBsonSerializer fieldSerializer) RenderFieldWithSerializer(FieldDefinition<TDocument> fieldDefinition, RenderArgs<TDocument> args)


RenderFieldWithSerializer might be sound like "Render the field with provided serializer"
Would RenderFieldAndGetFieldSerializer be more accurate?

Yes, I think it makes sense

BorisDog · 2025-02-07T03:27:20Z

tests/MongoDB.Driver.Tests/Search/SearchDefinitionBuilderTests.cs

-            AssertRendered(
-                subject.Equals("x", value),
-                $"{{ equals: {{ path: 'x', value: {valueRendered} }} }}");
+            //There is no property called "x" where to pick up a properly configured GuidSerializer for the tests


I'm not sure I fully understand this exclusion. Is the default guid serializer different from the one used by serialization?

I think I need to improve the comment, I agree it's not super clear.
The issue here is that when we use a string path, we're going to get the default serializer for the value, so GuidSerializer. In v3.0 we decided to have GuidRepresentation.Unspecified as the default Guid representation, and this will throw an exception when trying to serialize/deserialize. Normally a user would go over this by registering a default GuidSerializer with the proper representation (BsonSerializer.Register...(GuidSerializer)), but we can't do it because the registered serializers are global and this would be a problem for all the other tests.

For the typed path on line 305 it's not an issue since we get the default field serializer from the class, and the Guid property has the BsonGuidRepresentation attribute on it.

This is more of a testing issue and should be solved when we can pass down the serialization domain 😁

BorisDog · 2025-02-07T03:31:27Z

tests/MongoDB.Driver.Tests/Search/SearchDefinitionBuilderTests.cs

@@ -313,29 +319,55 @@ public void Equals_should_render_supported_type<T>(
            new object[] { (float)1, "1", Exp(p => p.Float), nameof(Person.Float) },
            new object[] { (double)1, "1", Exp(p => p.Double), nameof(Person.Double) },
            new object[] { DateTime.MinValue, "ISODate(\"0001-01-01T00:00:00Z\")", Exp(p => p.Birthday), "dob" },
-            new object[] { DateTimeOffset.MaxValue, "ISODate(\"9999-12-31T23:59:59.999Z\")", Exp(p => p.DateTimeOffset), nameof(Person.DateTimeOffset) },
+            new object[] { DateTimeOffset.MaxValue, """{ "DateTime" : { "$date" : "9999-12-31T23:59:59.999Z" }, "Ticks" : 3155378975999999999, "Offset" : 0 }""", Exp(p => p.DateTimeOffset), nameof(Person.DateTimeOffset) },


So does this mean that we are changing the defaults also for non typed queries (SearchDefinitionBuilder<BsonDocument>)?

If so, that might be considered a bug and a breaking change.

Yes it will change also for non typed queries. They would need to convert the DateTime themselves if they want to keep the same behaviour.

It's probably a breaking change, but I'm not sure this can be considered a bug. If you're working directly with Bson documents then I assume that you would like to control how to the values are serialized in any case.

papafe · 2025-02-07T07:02:01Z

@BorisDog, as an additional note. I've tried making an untyped query (using BsonDocument) and passing a DateTime value for the Equal operator. No error returned but zero results as expected.

rstam · 2025-02-10T22:26:11Z

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

@@ -42,7 +45,8 @@ public AutocompleteSearchDefinition(
            _fuzzy = fuzzy;
        }

-        private protected override BsonDocument RenderArguments(RenderArgs<TDocument> args) =>
+        private protected override BsonDocument RenderArguments(RenderArgs<TDocument> args,
+            IBsonSerializer fieldSerializer = null) =>


Once you can't put all arguments on a single line switch to a new line for each argument so that it's easy to see the arguments.

private protected override BsonDocument RenderArguments( RenderArgs<TDocument> args, IBsonSerializer fieldSerializer) {

Same in all other similar methods in this file.

Also... I would recommend against making the new fieldSerializer argument optional. Better to force the callers to pass in null if necessary.

Otherwise it's just to easy to forget to pass in optional arguments, specially in existing code.

Fix indentation of new()

rstam · 2025-02-10T22:28:03Z

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

+        private protected override BsonDocument RenderArguments(RenderArgs<TDocument> args,
+            IBsonSerializer fieldSerializer = null)
+        {
+            var valueSerializer = fieldSerializer switch


Seems like there is some common code here that could be moved to the base class?

It's actually a little different between the various operators, so I'd prefer to keep it here

rstam · 2025-02-10T22:31:33Z

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

@@ -305,7 +304,8 @@ public NearSearchDefinition(
            _pivot = pivot;
        }

-        private protected override BsonDocument RenderArguments(RenderArgs<TDocument> args) =>
+        private protected override BsonDocument RenderArguments(RenderArgs<TDocument> args,
+            IBsonSerializer fieldSerializer = null) =>


Fix indentation of new()

rstam · 2025-02-10T22:32:13Z

src/MongoDB.Driver/Search/OperatorSearchDefinitions.cs

@@ -483,7 +488,8 @@ public WildcardSearchDefinition(
            _allowAnalyzedField = allowAnalyzedField;
        }

-        private protected override BsonDocument RenderArguments(RenderArgs<TDocument> args) =>
+        private protected override BsonDocument RenderArguments(RenderArgs<TDocument> args,
+            IBsonSerializer fieldSerializer = null) =>


Fix indentation of new()

rstam · 2025-02-10T22:34:45Z

src/MongoDB.Driver/Search/SearchDefinition.cs

            return new(_operatorType.ToCamelCase(), renderedArgs);
        }

-        private protected virtual BsonDocument RenderArguments(RenderArgs<TDocument> args) => new();
+        private protected virtual BsonDocument RenderArguments(RenderArgs<TDocument> args,
+            IBsonSerializer fieldSerializer = null) => new();


Once you can't put all arguments on a single line switch to a new line for each argument so that it's easy to see the arguments:

private protected virtual BsonDocument RenderArguments( RenderArgs<TDocument> args, IBsonSerializer fieldSerializer)

rstam · 2025-02-10T22:39:40Z

src/MongoDB.Driver/Search/SearchPathDefinition.cs

@@ -104,11 +105,17 @@ public static implicit operator SearchPathDefinition<TDocument>(List<string> fie
        /// <param name="args">The render arguments.</param>
        /// <returns>The rendered field.</returns>
        protected string RenderField(FieldDefinition<TDocument> fieldDefinition, RenderArgs<TDocument> args)
+            => RenderFieldAndGetFieldSerializer(fieldDefinition, args).renderedPath;
+
+        internal virtual (BsonValue, IBsonSerializer) RenderAndGetFieldSerializer(RenderArgs<TDocument> args) => (Render(args), null);


Once you can't put all arguments on a single line switch to a new line for each argument so that it's easy to see the arguments.

I would recommend that instead of returning a Tuple we use an out parameter:

internal virtual BsonValue Render(RenderArgs<TDocument> args, out IBsonSerializer fieldSerializer)

I think it makes more sense, because the main point is to Render the args and getting the fieldSerializer is secondary.

rstam · 2025-02-10T22:42:05Z

src/MongoDB.Driver/Search/SearchPathDefinitionBuilder.cs

@@ -144,6 +145,9 @@ public SingleSearchPathDefinition(FieldDefinition<TDocument> field)

        public override BsonValue Render(RenderArgs<TDocument> args) =>
            RenderField(_field, args);
+
+        internal override (BsonValue, IBsonSerializer) RenderAndGetFieldSerializer(RenderArgs<TDocument> args)
+            => RenderFieldAndGetFieldSerializer(_field, args);


If you accept my other suggestions this would become:

internal override BsonValue Render(RenderArgs<TDocument> args, out IBsonSerializer fieldSerializer) => RenderField(_field, args, out fieldSerializer);

rstam · 2025-02-10T22:53:57Z

src/MongoDB.Driver/Search/SearchPathDefinition.cs

+
+        internal virtual (BsonValue, IBsonSerializer) RenderAndGetFieldSerializer(RenderArgs<TDocument> args) => (Render(args), null);
+
+        internal (string renderedPath, IBsonSerializer fieldSerializer) RenderFieldAndGetFieldSerializer(FieldDefinition<TDocument> fieldDefinition, RenderArgs<TDocument> args)


Consider declaring and implementing like this instead:

internal string RenderField( FieldDefinition<TDocument> fieldDefinition, RenderArgs<TDocument> args, out IBsonSerializer fieldSerializer) { var renderedField = fieldDefinition.Render(args); var prefix = args.PathRenderArgs.PathPrefix; fieldSerializer = renderedField.FieldSerializer; return prefix == null ? renderedField.FieldName : $"{prefix}.{renderedField.FieldName}"; }

papafe · 2025-02-11T10:44:41Z

@rstam @BorisDog I've followed Robert's suggestions about the code style.
I've also come up with an extension method to enable the new behaviour, so this won't be a breaking change. It's all in the last commit, so it can be reverted if necessary

papafe requested a review from BorisDog December 31, 2024 15:29

papafe commented Jan 2, 2025

View reviewed changes

papafe requested a review from rstam January 2, 2025 16:36

rstam requested changes Jan 3, 2025

View reviewed changes

papafe commented Jan 6, 2025

View reviewed changes

tests/MongoDB.Driver.Tests/Search/SearchDefinitionBuilderTests.cs Outdated Show resolved Hide resolved

papafe commented Jan 7, 2025

View reviewed changes

src/MongoDB.Driver/FieldValueSerializerHelper.cs Outdated Show resolved Hide resolved

papafe commented Jan 7, 2025

View reviewed changes

tests/MongoDB.Driver.Tests/Search/SearchDefinitionBuilderTests.cs Show resolved Hide resolved

papafe commented Jan 7, 2025

View reviewed changes

src/MongoDB.Driver/Search/SearchDefinition.cs Outdated Show resolved Hide resolved

papafe commented Jan 7, 2025

View reviewed changes

src/MongoDB.Driver/Search/SearchDefinitionBuilder.cs Outdated Show resolved Hide resolved

papafe requested review from rstam and sanych-sun and removed request for BorisDog January 7, 2025 11:42

papafe marked this pull request as ready for review January 7, 2025 15:32

papafe requested a review from a team as a code owner January 7, 2025 15:32

rstam requested changes Jan 7, 2025

View reviewed changes

papafe commented Jan 8, 2025

View reviewed changes

tests/MongoDB.Driver.Tests/Search/SearchDefinitionBuilderTests.cs Show resolved Hide resolved

papafe requested a review from rstam January 8, 2025 10:24

rstam approved these changes Jan 10, 2025

View reviewed changes

papafe requested a review from BorisDog January 28, 2025 19:52

BorisDog requested changes Feb 4, 2025

View reviewed changes

papafe requested a review from BorisDog February 6, 2025 20:26

BorisDog requested changes Feb 7, 2025

View reviewed changes

papafe added 3 commits February 7, 2025 07:45

Initial

850da0e

Various corrections

1f7261f

Corrections

e0eaa2e

papafe added 19 commits February 7, 2025 07:45

Added support for In

7758984

Added support for range

dd44330

Corrected tests

0a52c2d

Small corrections

96695fc

Small correction to tests

e471aca

Test correction

df4b1f6

Remove comment

e7b8662

Moved method

a7e19fe

Name corrections

1ab393e

Fixes according to PR

e4c7680

Small fixes

b665c8e

Corrected TField to TValue for better clarity

93641b1

Small fix

d0cb4e4

Correction to avoid path rendering twice

15ae2f2

Small fix

b06beca

Small fix

d4fc5e3

Fixes according to PR

7d8ae20

Improvement

4723bea

Small corrections according to PR

ba81027

papafe force-pushed the charp5442 branch from 1dc887d to ba81027 Compare February 7, 2025 06:46

rstam self-requested a review February 10, 2025 22:19

rstam requested changes Feb 10, 2025

View reviewed changes

papafe added 4 commits February 11, 2025 09:38

Fixed indentation

9136018

Corrections according to PR

70422e9

Naming correction

1fd8323

Added extension method to support old and new behaviour

213876e

papafe requested review from BorisDog and rstam February 11, 2025 10:44


		var renderedField = _arrayField.Render(args);

		var serializer =


		internal virtual (BsonValue, IBsonSerializer) RenderAndGetFieldSerializer(RenderArgs<TDocument> args) => (Render(args), null);

		internal (string renderedPath, IBsonSerializer fieldSerializer) RenderFieldWithSerializer(FieldDefinition<TDocument> fieldDefinition, RenderArgs<TDocument> args)

CSHARP-5442: Atlas Search doesn't respect the correct serializer #1583

Are you sure you want to change the base?

CSHARP-5442: Atlas Search doesn't respect the correct serializer #1583

Conversation

papafe commented Dec 31, 2024 • edited Loading

papafe commented Dec 31, 2024 • edited Loading

Choose a reason for hiding this comment

papafe Jan 2, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

papafe Jan 6, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

papafe Jan 6, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rstam left a comment

Choose a reason for hiding this comment

papafe commented Jan 14, 2025

papafe commented Jan 28, 2025

Choose a reason for hiding this comment

papafe Feb 5, 2025 • edited Loading

Choose a reason for hiding this comment

BorisDog Feb 5, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

papafe commented Feb 6, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

papafe commented Feb 7, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

papafe commented Feb 11, 2025

papafe commented Dec 31, 2024 •

edited

Loading

papafe commented Dec 31, 2024 •

edited

Loading

papafe Jan 2, 2025 •

edited

Loading

papafe Jan 6, 2025 •

edited

Loading

papafe Jan 6, 2025 •

edited

Loading

papafe Feb 5, 2025 •

edited

Loading

BorisDog Feb 5, 2025 •

edited

Loading