We have noticed a unique issue with the “delivery-address.render-after” checkout UI extension target, where it seems to time out and never get mounted under throttled network conditions.
At first we suspected it was some extension logic causing the issue, so we removed all of the logic and had it just return a banner with static text content. However, it still wasn’t showing up, and we were still seeing a console error in the browser saying, “ExtensionTimeoutError: Extension [ID] timed out while mounting”. Other extensions were still loading properly, albeit slowly.
So we decided to add two new extensions to the same app, each with a different target and also just outputting a static banner. The checkout profile looks like this:
The three gray banners correspond to our app’s extensions.
We then added a single product to the cart, throttled the network to 3G in Chrome, disabled the cache, and went to the checkout page. The result was the following:
We see that the two banners with targets other than “delivery-address.render-after” render fine, while the one in question still does not. Again, in the console there is a single “ExtensionTimeoutError” message. If we turn off the throttling, all three extensions render as expected:
Something to note is that the network conditions must be pretty bad to replicate this. Throttling to slow 4G or removing some of the other extensions/pixels will prevent the issue from occurring for the most part. However, the extensions/pixels we added to this test store were selected based on one of our merchant’s stores who was having an issue. Our app’s job is to block checkout based on ZIP/province + product combinations, and the merchant found a few orders were making it through in the last couple months. Our app’s logs indicated that in those cases, the extension never ran. They are a very high volume store, doing around 2000 orders a day, so their customers would have a huge range of network conditions in a two month sample size.
The main question we have is why does this issue seem to be exclusive to the “delivery-address.render-after” target, and if there is something that can be done so that it behaves like the other targets under harsh network conditions. The test store with these banners is joltflame.com.
Thanks,
Alex