No payments since update v4.1 to v4.2 on Shopware 6.4.20.2

[cardboarder]

Since we updated yesterday, the plugin can no longer create payments:

[2023-10-10T23:38:41.003815+00:00] Mollie.ERROR: Error when starting Mollie payment: Call to a member function getSettings() on null {"function":"order-prepare","exception":"[object] (Error(code: 0): Call to a member function getSettings() on null at /home/XXXXXX/domains/XXXXXXXX.com/public_html/custom/plugins/MolliePayments/src/Service/MollieApi/Builder/MollieOrderBuilder.php:138)"} {"file":"/home/XXXXX/domains/YYYYY.com/public_html/custom/plugins/MolliePayments/src/Handler/PaymentHandler.php","line":129,"class":"Kiener\MolliePayments\Handler\PaymentHandler","callType":"->","function":"pay","url":"/account/order/update/65e03201cc394725b2b4c9e3465edf31","ip":"XXX.XXX.XXX.XXX","http_method":"POST","server":"www.XXXXXXX.com","referrer":"https://www.YYYYY.com/account/order/edit/yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyUID?error-code=CHECKOUT__MOLLIE_COULD_NOT_CREATE_PAYMENT_URL"}

Worked fine with v4.1.
API per se seems to be OK, validating keys and payment methods showed no errors.

[boxblinkracer]

Hi

thank you for this
this is really weird, because nothing has changed in there
the SettingsService is still assigned using DI to the MollieOrderBuilder where it is just used. it somehow says that the SettingsService is NULL

can you try to clear your caches? also when does it happen, is there a special scenario or specific payment method?

thank you

[cardboarder]

Hi,

all we did was to update from version 4.1 to version 4.2, and (yes, this is kind of a meme! :-) ) it worked before!
Of course the cache has been cleared multiple times, both via SW backend and via CLI. Also, the plugin has been de- and reactivated (with cache clears inbetween). No effect.
It happens with all payment methods (Mollie) under all known cirumstances. Non-Mollie payment like money transfer works.

This morning, I tried to get into the problem (I know a bit of PHP, but Symfony drives me crazy!).
So, this line in MollieOrderBuilder.php fails:
$settings = $this->settingsService->getSettings($order->getSalesChannelId());
If I understood that right, getSettings() reports null if no or an invalid parameter is passed to the function getSettings() in settingsService.php, so the main problem seems to be that $order->getSalesChannelId() fails.

My first idea about that was: Why isn't that $salesChannelContext->getSalesChannelId() anyhow?
Or does $salesChannelContext->getSalesChannelId() NOT equal $order->getSalesChannelId()?

The use of these methods that, in my opinion, should return the same result, is somewhat inconsitant throughout the whole plugin - sometimes one is used, sometimes the other.
Is there a reason for it?

We use at least one plugin that is manipulating the user's basket. May be that is why $order->getSalesChannelId() fails?
(This plugin was already active long before the update, just to mention that)

Dieter

[cardboarder]

Jesus... there are chances the problem is actually caused by that plugin... there also was an update, but it has been update later than Mollie!? At least on our DEV shop, we can confirm that Mollie works when this Acris plugin is disabled:

https://store.shopware.com/acris46666885748/zuschlaege-und-rabatte.html

Acris is informed.
I'll keep you updated.

Dieter

[boxblinkracer]

Hi Dieter

aaaaa, so a side effect by the acris plugin? that is the only thing that would make sense to me
so just to clarify things, if that plugin is installed, then our SettingsService seems to be NULL somehow, or whatever is going on

because maybe we can also try to improve something while Acris is fixing it

does that sound correct?

thanks

[cardboarder]

jep, we just placed a bunch of test orders on our DEV system, switching the Acris on/off, and Mollie fails at the position mentioned above when Acris is ON.
We are using both plugins since 2022, no problems until now.
Of course, as both plugins have been updated almost at the same time, I'm not sure in which combination the fail occurs.
May be Mollie 4.2 and Acris 3.10.8 was still fine or Mollie 4.1 and Acris 3.10.9 was?? At least, in the current combination (4.2 and 3.10.9) the darn NULL error comes up.

[cardboarder]

At least, it would be great if you could check my assumption that

$salesChannelContext->getSalesChannelId() SHOULD BE equal $order->getSalesChannelId()

because, if I'm right, I guess that using $salesChannelContext would be much safer.
Obviously, $order can be modified by other plugins and is not really reliable for this purpose.

[boxblinkracer]

Hi

thank you so much for your help. so we will create an internal ticket to improve what we can improve.
and yes, you are right with the sales channel ID. we usually use the order->getSalesChannel for async. things like webhooks, but in the step where the order is placed, it shouldnt make a difference, although order one would still be better

thank you so much for your help

[cardboarder]

Ah, ok, I understand - the two methods have the same results, but the ways the results are retrieved are different.

Suggestion:
May be you can "try" a fallback to $salesChannelContext in Case $order returns null??

[boxblinkracer]

yeah we find a way,
but the problem is not that this is null or anything but this

call to a mamber function getSettings() on NULL not possible =>

This means that $this->settingsService is NULL and not that the argument of that function is null

so the problem is in the contructor or anything else it seems...so side effect thru side effect haha

[cardboarder]

Hm..... I'm not sure about that?
The function getSettings() in settingsService.php starts like this:
public function getSettings(?string $salesChannelId = null): MollieSettingStruct
{ ... }

So, if nothing (or invalid) stuff is sent as argument, the function would return null - that's at least how I understand that ternary operator: initialise var $salesChannelId and set it to null if empty (no argument passed)
Result: the function returns null. That's what happens, and the line in MollieOrderBuilder.php would read like:
$settings = $this->settingsService->null

May be stupid, but that's how I understand it. As I said: I know a bit about PHP, but I'm a total Symfony noob! ;-)

[boxblinkracer]

almost
usually this

Call to a member function getSettings() on null

means that there is access to a function ->getSettings(), but it is invoked on an object which does not exist (null).
the response would only lead to this error if the response would be used
so like this

$this->settingsService->getSettings($order->getXY())->getApiKeySetting();

but then it would show sth like this

Call to a member function getApiKeySetting() on null

this would mean the response is NULL

[cardboarder]

Okay, I hope i got that! Thanks for explaining! ;-)

BTW: Acris has confirmed that the problem is caused by their plugin and managed to provide an update within just one hour!
We just did first tests on the DEV system and it seems to work! :-)

[boxblinkracer]

wow this is great
acris is super
thx for letting us know

[cardboarder]

Acris is awesome, this is not the first time they helped me out!
And thanks to you for helping me ;-)
Topic closed ;-)
Dieter

[boxblinkracer]

perfect :)
then i will close this ticket, have a great week