Refunds are processed in PayPal despite expected State error in Drupal

Do you have any error to share from the logs?

    catch (BadResponseException $exception) {
      $this->logger->error($exception->getResponse()->getBody()->getContents());
      throw new PaymentGatewayException('An error occurred while refunding the payment.');
    }

    if (strtolower($response['status']) !== 'completed') {
      throw new PaymentGatewayException(sprintf('Invalid state returned by PayPal. Expected: ("%s"), Actual: ("%s").', 'COMPLETED', $response['status']));
    }

The error should be logged...What was displayed in the UI as well? Could be that the response has changed and the status isn't "COMPLETED" as expected? Is this a partial refund?

I just tried reproducing this locally and couldn't... I'd appreciate if we could get a screenshot / dump of the response. I just tried performing a partial and a full refund and both worked, see the attached screenshots:

hm... Quick q: do you have Webhooks configured? I'm wondering if there is a race condition or something... Since I'm testing locally this isn't happening to me.

Can you confirm if you have Webhooks configured? If so, I think we might have an issue where the webhook is actually causing a double refund... Not really sure how we can prevent that unfortunately...
We'd either need to know that a particular event was processed or whether the refund was initiated from Drupal... Basically the intent was to make sure refunds initiated from PayPal directly would be reflected into Drupal.

In the meantime, perhaps you can stop listening to the PAYMENT.CAPTURE.REFUNDED event?

Chatted with Ryan on this on Slack. We should check if it is possible to embed context in the API request so we can easily identify events that were initiated from on site activity (e.g: a refund triggered from the Drupal admin).

UPDATE: PayPal doesn't support arbitrary metadata fields like Stripe does, so we can't attach a key-value pair like "source": "drupal" and expect to see it in webhooks. We're not passing a "custom_id" whenever the refund is initiated but we are expecting it in the Webhook, which makes me think it is inherited from when the PayPal order is created.
We could use "invoice_id" as well but that might be reflected somewhere in the PayPal UI and that field has an associated meaning.

@tonytheferg: Anyway you could test the patch?

Ok so my analysis isn't correct even though I believe this is also a problem.
Could you check if the status returned was "pending" perhaps? We can't consider "pending" refunds as "completed", so perhaps we should add special handling for this and add a message informing the merchant.
Anything else that could help us further diagnose the issue?

If webhooks are configured properly, then I believe the payment would be later marked as refunded.

Will merge the MR (that is unrelated), but update this issue status back to Postponed until more information is provided.

But do you have logs for the problematic refund?

@jsacksick you forgot to initiate the UUID service! Which currently leads to the following error when refunding:

Error: Call to a member function generate() on null in Drupal\commerce_paypal\Plugin\Commerce\PaymentGateway\Checkout->refundPayment() (line 669 of modules/contrib/commerce_paypal/src/Plugin/Commerce/PaymentGateway/Checkout.php).

Fixed this and tagged a new release.

Thank you!