Introduce `VerifyOnlyElementInFlux` Refaster rule #617

giovannizotta · 2023-05-07T22:52:00Z

When verifying a Flux only has one element, avoid collecting to list.

Notes:

The @BeforeTemplate is quite big, can it be a problem? I don't know if/how it can be reduced in size;
I am pretty sure the name of the rule is not the best, please suggest one that follows existing standards if you have better ideas;
It could be extended to toImmutableSet as well (see comment)
I used flux.collect(toImmutableList()) instead of flux.collectList() because of the rule FluxCollectToImmutableList;
How does it work if there is a match for this rule, but with flux.collectList()? Will error-prone perform "two passes" and first move flux.collectList() to flux.collect(toImmutableList()) and then apply my rule?

github-actions · 2023-05-07T22:54:03Z

Looks good. No mutations were possible for these changes.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

Stephan202

Nice draft, in the small hours of the day ;)

giovannizotta · 2023-05-08T07:43:27Z

Nice draft, in the small hours of the day ;)

The best ones, right? 😄

giovannizotta · 2023-05-08T21:59:05Z

I wanted to extend the rule by also accepting inputs that match flux.collect(toImmutableSet()), but it doesn't work because of different semantics:

In @BeforeTemplate, we would be testing if the flux has only one unique element while allowing to have that one unique element multiple times.
In AfterTemplate we would be testing if the flux has only one element;

But (!) while I was trying to make the rule work, I found a very weird situation that I cannot explain.

The first version of the @BeforeTemplate worked well:

@BeforeTemplate
Duration before(Flux<T> flux, T object) {
  return flux.collect(toImmutableList())
      .as(StepVerifier::create)
      .assertNext(collection -> assertThat(collection).containsExactly(object))
      .verifyComplete();
}

Alongside flux.collect(toImmutableList()), I wanted to add support for flux.collect(toImmutableSet()), so I wrote the following:

@BeforeTemplate
Duration before(Flux<T> flux, T object) {
  return Refaster.anyOf(flux.collect(toImmutableList()), flux.collect(toImmutableSet()))
      .as(StepVerifier::create)
      .assertNext(collection -> assertThat(collection).containsExactly(object))
      .verifyComplete();
}

I am not sure how Refaster#anyOf works, but the following is very weird. Let's say I have the following test:

ImmutableSet<Duration> testVerifyOnlyElementInFlux() {
  return ImmutableSet.of(
      Flux.just(1)
          .collect(toImmutableList())
          .as(StepVerifier::create)
          .assertNext(list -> assertThat(list).containsExactly(1))
          .verifyComplete(),
      Flux.just(2)
          .collect(toImmutableSet())
          .as(StepVerifier::create)
          .assertNext(set -> assertThat(set).containsExactly(2))
          .verifyComplete());
}

I would expect the result to be:

ImmutableSet<Duration> testVerifyOnlyElementInFlux() {
  return ImmutableSet.of(
      Flux.just(1).as(StepVerifier::create).expectNext(1).verifyComplete(),
      Flux.just(2).as(StepVerifier::create).expectNext(2).verifyComplete());
}

The fun part? Now the rule does not match flux.collect(toImmutablelist()), but instead it matches flux.collect(toImmutableSet()) (notice that the second test succeded):

diff (-expected +actual):
    @@ -438,7 +438,11 @@
     
       ImmutableSet<Duration> testVerifyOnlyElementInFlux() {
         return ImmutableSet.of(
    -        Flux.just(1).as(StepVerifier::create).expectNext(1).verifyComplete(),
    +        Flux.just(1)
    +            .collect(toImmutableList())
    +            .as(StepVerifier::create)
    +            .assertNext(list -> assertThat(list).containsExactly(1))
    +            .verifyComplete(),
             Flux.just(2).as(StepVerifier::create).expectNext(2).verifyComplete());
       }
     }

Am I missing something? Am I using Refaster#anyOf in a wrong way? What kind of sorcery is this?

rickie

The @BeforeTemplate is quite big, can it be a problem? I don't know if/how it can be reduced in size;

I proposed a change that makes it one line smaller. In general, this is not really a problem as we are matching a bigger statement in this case.

I am pretty sure the name of the rule is not the best, please suggest one that follows existing standards if you have better ideas;

I applied our future naming algorithm which is based on the content of the after template.

It could be extended to toImmutableSet as well (see comment)
I used flux.collect(toImmutableList()) instead of flux.collectList() because of the rule FluxCollectToImmutableList;

Yes that is a good idea. I pushed some changes to make it work. I also tried it with Refaster#anyOf but it didn't really work that well 🤔. With the more specific before template it seems better to have two different before templates because of the Immutable{List,Set}<T> in the return types.

How does it work if there is a match for this rule, but with flux.collectList()? Will error-prone perform "two passes" and first move flux.collectList() to flux.collect(toImmutableList()) and then apply my rule?

Yes Error Prone will fix it in two runs. That's why our internal patch.sh script runs again when changes are introduced by Error Prone.

Added a commit with some changes 😄, thanks for opening the PR 🚀 !

rickie · 2023-05-09T12:28:33Z

...-contrib/src/test/resources/tech/picnic/errorprone/refasterrules/ReactorRulesTestOutput.java

@@ -435,4 +435,8 @@ Duration testStepVerifierLastStepVerifyErrorMessage() {
  Duration testStepVerifierLastStepVerifyTimeout() {
    return StepVerifier.create(Mono.empty()).verifyTimeout(Duration.ZERO);
  }
+
+  Duration testVerifyOnlyElementInFlux() {
+    return Flux.just(1).as(StepVerifier::create).expectNext(1).verifyComplete();


Let's use distinct values in the tests :).

rickie · 2023-05-09T12:28:40Z

error-prone-contrib/src/main/java/tech/picnic/errorprone/refasterrules/ReactorRules.java

+
+    @AfterTemplate
+    Duration after(Flux<T> flux, T object) {
+      return flux.as(StepVerifier::create).expectNext(object).verifyComplete();


Suggested change

return flux.as(StepVerifier::create).expectNext(object).verifyComplete();

return flux.as(StepVerifier::create).expectNext(object);

Besides the fact that the return types are now slightly different we can drop the verifyComplete part.
Assuming the tests pass, we can do this rewrite as we test that the list literally contains one object. Strictly speaking this is not a behavior preserving change because of the updated return type. The verifyComplete should be able to handle it though.

As a result we should also move this up as it belongs with the other StepVerifier.Step return type rules.

Should've replied to this comment :) #617 (comment)

rickie · 2023-05-09T12:33:43Z

Am I missing something? Am I using Refaster#anyOf in a wrong way? What kind of sorcery is this?

Hmm, I tried looking into this and combining them but had the same issue.

As before template I had the following:

    @BeforeTemplate
    StepVerifier.Step<? extends ImmutableCollection<T>> before(Flux<T> flux, T object) {
      return Refaster.anyOf(flux.collect(toImmutableList()), flux.collect(toImmutableSet()))
          .as(StepVerifier::create)
          .assertNext(list -> assertThat(list).containsExactly(object));
    }

Had the same problem, requires some more brain cycles at a different point in time :). Now have to focus on something else.

(Note to self: didn't check the Javadoc yet)

sonarqubecloud · 2023-05-09T12:35:30Z

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

github-actions · 2023-05-09T12:36:13Z

Looks good. No mutations were possible for these changes.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

giovannizotta · 2023-05-11T06:22:13Z

Hey @rickie thanks for the review! I won't have much time in the next days, but I'll pick this up.

Just one thing about making it one line smaller: in my understanding, if we don't check for verifyComplete() we could have a situation where the input does not do verifyComplete(), and the output would give a warning Unfinished step verifier.

I'll come back to this asap, probably in the weekend 😄

Stephan202

Had a quick peek; nice rule!

Just one thing about making it one line smaller: in my understanding, if we don't check for verifyComplete() we could have a situation where the input does not do verifyComplete(), and the output would give a warning Unfinished step verifier.

As-is the rule will match both with and without verifyComplete(), meaning it's more generic; a property we generally like. It's okay if a rule also matches code that is "otherwise wrong" 😄

Stephan202 · 2023-05-11T11:46:01Z

error-prone-contrib/src/main/java/tech/picnic/errorprone/refasterrules/ReactorRules.java

+      return flux.collect(toImmutableSet())
+          .as(StepVerifier::create)
+          .assertNext(set -> assertThat(set).containsExactly(object));


This is not equivalent to the code below, since toImmutableSet() drops duplicates. We could add an XXX comment, or drop this case 🤔.

(If we keep it: Should indeed have a closer look at that Refaster#anyOf issue.)

Hmm, that would indeed be the best option. Might find some time for that later this week, but not sure.

TBH, I think fixing this issue requires creating a Refaster rule in Error Prone and debugging why this specific Refaster#anyOf usage doesn't work. That sounds like a bit more work. I'd suggest to drop the toImmutableSet() and create an XXX and pick up that debugging later. WDYT? @Stephan202

Stephan202 · 2023-05-11T11:47:42Z

error-prone-contrib/src/main/java/tech/picnic/errorprone/refasterrules/ReactorRules.java

@@ -1295,6 +1295,28 @@ StepVerifier.Step<T> after(StepVerifier.Step<T> step, T object) {
    }
  }

+  /** Avoid collecting when verifying only the given element is in the given {@link Flux}. */


Suggested change

/** Avoid collecting when verifying only the given element is in the given {@link Flux}. */

/** Avoid value collection when verifying that a {@link Flux} emits exactly one value. */

giovannizotta · 2023-05-20T14:55:32Z

As-is the rule will match both with and without verifyComplete()

Isn't this a problem? Let's say the original code is:

Flux.just(1)
    .collect(toImmutableList())
    .as(StepVerifier::create)
    .assertNext(list -> assertThat(list).containsExactly(1));

This code is correct and does not give warnings. We are sure the flux is completed because we collected to list and then verified the only element in the list was the expected one.
In the new code:

Flux.just(1).as(StepVerifier::create).expectNext(1);

We are not verifying if the flux is completed, which gives the warning Unfinished StepVerifier. So we are turning code that compiles into code that gives a warning, that does not seem right to me?

Stephan202 · 2023-05-20T17:22:42Z

This code is correct and does not give warnings. We are sure the flux is completed because we collected to list and then verified the only element in the list was the expected one.

That code might not yield a warning, but that's just a limitation of IDEA; it is just as incorrect. Neither variant verifies anything 😬.

The following check should fail, but doesn't (because there's no verification):

Flux.just(2)
    .collect(toImmutableList())
    .as(StepVerifier::create)
    .assertNext(list -> assertThat(list).containsExactly(1));

giovannizotta · 2023-06-18T13:36:50Z

I am sorry for not coming back at this for more than a month, it has been really busy lately 😄 I hope there's no rush.

To be honest, I still don't understand. Take the following snippet:

@BeforeTemplate
StepVerifier.Step<ImmutableList<T>> before(Flux<T> flux, T object) {
  return flux.collect(toImmutableList())
      .as(StepVerifier::create)
      .assertNext(list -> assertThat(list).containsExactly(object));
}

@AfterTemplate
StepVerifier.Step<T> after(Flux<T> flux, T object) {
  return flux.as(StepVerifier::create).expectNext(object);
}

The code in the @BeforeTemplate collects the flux in a Mono<ImmutableList<T>> and checks that the list contains one and only one element, and checks if it is specifically the one we're looking for.
The code in the @AfterTemplate is checking if the first element of the flux is the one we're looking for. However, it does not have any check on the length of the flux.
To me without the verifyComplete() on the @AfterTemplate, these 2 templates are testing different things and therefore not a great fit for error-prone, unless I am missing something (which is likely 😄).
Am I missing something? Please let me know. No rush though, and again, sorry for the delay 😅

github-actions · 2023-06-18T17:35:23Z

Looks good. No mutations were possible for these changes.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

mohamedsamehsalah · 2023-07-03T15:15:10Z

@giovannizotta Am I missing something? Please let me know. No rush though, and again, sorry for the delay 😅

Hello, just passing through 👀

I think the confusion is that

  return flux.collect(toImmutableList())
      .as(StepVerifier::create)
      .assertNext(list -> assertThat(list).containsExactly(object));

is also checking for one and only one element (Since we only have one assertNext call)

As far as I can tell, the @AfterTemplate is the less verbose method to check for this.

giovannizotta · 2023-07-03T16:11:27Z

Hey @mohamedsamehsalah thanks for passing by!
The issue I see is the opposite:

the @BeforeTemplate is checking that the flux has one and only one element, and that the element corresponds to the one we're looking for
the @AfterTemplate is checking that the flux has at least one element, and that the first element corresponds to the one we're looking for. However no checks that the flux contains only one element.

So they are testing two different things 🤔

rickie · 2023-07-06T14:48:25Z

Thanks for thoroughly thinking about this and explaining your thought process, I like it 😄!

One important assumption we are making here, which should be true for 99% of the cases, is that someone is using something like verifyComplete() after the assertNext. As Stephan mentions here, while the code doesn't yield a warning, it doesn't verify anything.

Having the @BeforeTemplate without .verifyComplete() makes it more generic, which should also be fine in most cases. If it appears that this is not the case, we can always decide to make the rule more strict. For example, by creating a Matcher (examples) that verifies that the assertNext is followed by a verifyComplete.
Another option what would maybe even be better is creating another check (probably a BugPattern would be better for this) that enforces that an assertNext is followed by an verifyComplete. That would even be better and make this Refaster rule 100% valid 😉. (We can probably make that rule more generic even).

these 2 templates are testing different things

So together with the knowledge that an assertNext is not verifying anything, and therefore the assumption that we have an verifyComplete(), we are actually doing a correct replacement.

Let's consider the following failing test:

 Flux.just(1, 2)
         .collect(toImmutableList())
         .as(StepVerifier::create)
         .assertNext(list -> assertThat(list).containsExactly(1))
         .verifyComplete();

Would correctly be rewritten to:

   Flux.just(1, 2)
        .as(StepVerifier::create)
        .expectNext(1)
        .verifyComplete();

Which would fail with:

java.lang.AssertionError: expectation "expectComplete" failed (expected: onComplete(); actual: onNext(2))

Here a quick (not fullproof) GitHub search on Picnic code that shows we are in all cases verifying.

If I'm missing anything in my explanation, please let me know 😄, happy to elaborate further!

github-actions · 2023-07-06T15:00:01Z

Looks good. No mutations were possible for these changes.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

giovannizotta · 2023-07-14T21:04:43Z

@rickie thanks a lot for the amazing explanation! Also, for the offline discussion 😄
Now it's very clear: I was confused on how the step verifier works, as I am really a reactive noobie. But the explanation makes a lot of sense 😄.

To finish up the PR, I decided to move on with the suggestion to remove the toImmutableSet() rule because of the different semantics. Also, at some point I would like to look into building the matcher you mentioned, but let's keep that for the future 🙂.

Just a question about the test framework. I tried minimising the test by removing the verifyComplete(), but that leads to having a different return type for the function in the before and after template.
The test framework does not substitute the return type, so if we give the proper return type to the After template we end up with a mismatch:

-  StepVerifier.Step<Integer> testFluxAsStepVerifierExpectNext() {
+  StepVerifier.Step<ImmutableList<Integer>> testFluxAsStepVerifierExpectNext() {

And if we give StepVerifier.Step<ImmutableList<Integer>> as a return type to the @After:

incompatible types: reactor.test.StepVerifier.Step<java.lang.Integer> cannot be converted to reactor.test.StepVerifier.Step<com.google.common.collect.ImmutableList<java.lang.Integer>>

So I decided to just stick to also having a verifyComplete() in the test to have a Duration as a return type in both cases.

github-actions · 2023-07-14T21:04:46Z

Looks good. No mutations were possible for these changes.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

github-actions · 2023-07-14T21:05:17Z

Looks good. No mutations were possible for these changes.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

github-actions · 2023-07-22T13:45:31Z

Looks good. No mutations were possible for these changes.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

github-actions · 2023-08-06T17:07:46Z

Looks good. No mutations were possible for these changes.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

rickie

Changes LGTM. Let's indeed not consider the toImmutableSet for now.

rickie · 2023-08-14T06:25:46Z

@giovannizotta Your reasoning about the tests is correct, we can use the verifyComplete there :).

github-actions · 2023-08-14T06:26:55Z

Looks good. No mutations were possible for these changes.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

Stephan202

Nice discussions!

Rebased and added a commit. Suggested commit message:

Introduce `FluxAsStepVerifierExpectNext` Refaster rule (#617)

Stephan202 · 2023-08-14T07:54:22Z

error-prone-contrib/src/main/java/tech/picnic/errorprone/refasterrules/ReactorRules.java

+  static final class FluxAsStepVerifierExpectNext<T> {
+    @BeforeTemplate
+    StepVerifier.Step<ImmutableList<T>> before(Flux<T> flux, T object) {
+      return flux.collect(toImmutableList())


Though it comes with some caveats, we can also match other list-producing collectors here, such as toCollection(ArrayList::new).

Stephan202 · 2023-08-14T07:55:05Z

...e-contrib/src/test/resources/tech/picnic/errorprone/refasterrules/ReactorRulesTestInput.java

+        .collect(toImmutableList())
+        .as(StepVerifier::create)
+        .assertNext(list -> assertThat(list).containsExactly(2))
+        .verifyComplete();


This .verifyComplete() can be omitted (which hides that we do change the return type here :).)

Ahh, we can do the <?> as return type indeed.

github-actions · 2023-08-14T09:22:42Z

Looks good. No mutations were possible for these changes.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

github-actions · 2023-08-14T09:22:53Z

Looks good. No mutations were possible for these changes.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

Stephan202 · 2023-08-14T09:23:02Z

...e-contrib/src/test/resources/tech/picnic/errorprone/refasterrules/ReactorRulesTestInput.java

+  ImmutableSet<StepVerifier.Step<?>> testFluxAsStepVerifierExpectNext() {
+    return ImmutableSet.of(
+        Flux.just(1)
+            .collect(toImmutableList())
+            .as(StepVerifier::create)
+            .assertNext(list -> assertThat(list).containsExactly(2)),
+        Flux.just(3)
+            .collect(toCollection(ArrayList::new))
+            .as(StepVerifier::create)
+            .assertNext(list -> assertThat(list).containsExactly(4)));
+  }


After pushing this I realized that perhaps for rule one test case would suffice, or at least be more consistent with what we do elsewhere. 🤷

I agree, I'll add a commit to drop the second test case.

rickie · 2023-08-14T11:35:39Z

Will merge once 🍏.

github-actions · 2023-08-14T11:36:59Z

Looks good. No mutations were possible for these changes.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

sonarqubecloud · 2023-08-14T11:37:26Z

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

Stephan202 reviewed May 8, 2023

View reviewed changes

giovannizotta marked this pull request as ready for review May 8, 2023 07:43

rickie reviewed May 9, 2023

View reviewed changes

Stephan202 reviewed May 11, 2023

View reviewed changes

rickie added this to the 0.12.0 milestone May 16, 2023

rickie added the new feature label May 16, 2023

giovannizotta force-pushed the giovannizotta/verifyonlyelementinflux branch from 5cad15f to 200aafc Compare June 18, 2023 17:33

Stephan202 modified the milestones: 0.12.0, 0.13.0 Jun 21, 2023

giovannizotta force-pushed the giovannizotta/verifyonlyelementinflux branch from 200aafc to 36444a3 Compare July 6, 2023 14:58

giovannizotta force-pushed the giovannizotta/verifyonlyelementinflux branch from 058a070 to 8492c5a Compare July 14, 2023 21:03

giovannizotta force-pushed the giovannizotta/verifyonlyelementinflux branch from 8492c5a to 6536c11 Compare July 22, 2023 13:43

giovannizotta force-pushed the giovannizotta/verifyonlyelementinflux branch from 6536c11 to db51011 Compare August 6, 2023 17:05

rickie approved these changes Aug 14, 2023

View reviewed changes

rickie force-pushed the giovannizotta/verifyonlyelementinflux branch from db51011 to 3da3627 Compare August 14, 2023 06:25

Stephan202 force-pushed the giovannizotta/verifyonlyelementinflux branch from 3da3627 to b198db4 Compare August 14, 2023 09:20

giovannizotta and others added 4 commits August 14, 2023 11:20

Initial implementation

0460653

Suggestions

0b94faa

Remove toImmutableSet() rule

1243644

Suggestions

1d52d89

Stephan202 force-pushed the giovannizotta/verifyonlyelementinflux branch from b198db4 to 1d52d89 Compare August 14, 2023 09:20

Stephan202 approved these changes Aug 14, 2023

View reviewed changes

Stephan202 reviewed Aug 14, 2023

View reviewed changes

Drop testcase

db04a3e

rickie merged commit 7fb0e55 into master Aug 14, 2023

rickie deleted the giovannizotta/verifyonlyelementinflux branch August 14, 2023 12:05

	return flux.as(StepVerifier::create).expectNext(object).verifyComplete();
	return flux.as(StepVerifier::create).expectNext(object);

	/** Avoid collecting when verifying only the given element is in the given {@link Flux}. */
	/** Avoid value collection when verifying that a {@link Flux} emits exactly one value. */

Introduce VerifyOnlyElementInFlux Refaster rule #617

Introduce VerifyOnlyElementInFlux Refaster rule #617

Conversation

giovannizotta commented May 7, 2023 • edited Loading

github-actions bot commented May 7, 2023

Stephan202 left a comment

Choose a reason for hiding this comment

giovannizotta commented May 8, 2023

giovannizotta commented May 8, 2023 • edited Loading

rickie left a 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

rickie commented May 9, 2023 • edited Loading

sonarqubecloud bot commented May 9, 2023

github-actions bot commented May 9, 2023

giovannizotta commented May 11, 2023

Stephan202 left a comment • edited by rickie 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

giovannizotta commented May 20, 2023

Stephan202 commented May 20, 2023

giovannizotta commented Jun 18, 2023 • edited Loading

github-actions bot commented Jun 18, 2023

mohamedsamehsalah commented Jul 3, 2023 • edited Loading

giovannizotta commented Jul 3, 2023 • edited Loading

rickie commented Jul 6, 2023

github-actions bot commented Jul 6, 2023

giovannizotta commented Jul 14, 2023

github-actions bot commented Jul 14, 2023

github-actions bot commented Jul 14, 2023

github-actions bot commented Jul 22, 2023

github-actions bot commented Aug 6, 2023

rickie left a comment

Choose a reason for hiding this comment

rickie commented Aug 14, 2023

github-actions bot commented Aug 14, 2023

Stephan202 left a 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

github-actions bot commented Aug 14, 2023

github-actions bot commented Aug 14, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rickie commented Aug 14, 2023

github-actions bot commented Aug 14, 2023

sonarqubecloud bot commented Aug 14, 2023

Introduce `VerifyOnlyElementInFlux` Refaster rule #617

Introduce `VerifyOnlyElementInFlux` Refaster rule #617

giovannizotta commented May 7, 2023 •

edited

Loading

giovannizotta commented May 8, 2023 •

edited

Loading

rickie commented May 9, 2023 •

edited

Loading

Stephan202 left a comment •

edited by rickie

Loading

giovannizotta commented Jun 18, 2023 •

edited

Loading

mohamedsamehsalah commented Jul 3, 2023 •

edited

Loading

giovannizotta commented Jul 3, 2023 •

edited

Loading