Skip to content

Conversation

thomas-kl1
Copy link
Contributor

@thomas-kl1 thomas-kl1 commented Jul 28, 2025

Prevent breaking changes when algoliasearch-magento-2 is updated.
The override over the product helper is too hard for a such small change, even more when it's already backed by MSI natively thanks to the 'adapt_add_stock_status_to_select' plugin.
I do face an error with Algolia M2 3.15.1 and the latest version of this module installed (1.2.0).

@thomas-kl1 thomas-kl1 marked this pull request as ready for review July 28, 2025 11:52
@cammonro
Copy link
Contributor

cammonro commented Aug 8, 2025

We understand that the plugin exists (as previously discussed in #1739), but it's not yet fully supported in any released version of our core module. Until we're able to include MSI support natively, this preference remains necessary — the relevant methods are currently protected, not public, so this is required for extension.

Feel free to share your use case and we can revisit but please know that at this time, we’re not able to prioritize additional changes in this area. Still we appreciate the feedback and understand this may be important for some implementations. Please also note that this module is maintained on a best-effort basis, with no guaranteed SLA (as outlined in our README).

cc @damcou @rachel-trott

@thomas-kl1
Copy link
Contributor Author

We had to remove the preference (because it doesn't bring any value) and it was throwing an error because the construct arguments were not matching the expected values from the parent.

@cammonro
Copy link
Contributor

That behavior shouldn't occur on a vanilla installation of either 3.15.x version unless there’s a version mismatch or customizations applied to the module. If you're able to provide reproducible steps, we can take a closer look.

While it’s true that the plugin acts as a fallback on the legacy \Magento\CatalogInventory\Helper\Stock class currently used in our core module, we’re opting to be more intentional here. This preference class explicitly defines the query logic rather than relying on deprecated classes and implicit behavior.

If this approach doesn’t suit your use case, you’re welcome to remove the preference locally — but we believe the current design is safer and more maintainable over time.

@thomas-kl1
Copy link
Contributor Author

thomas-kl1 commented Sep 1, 2025

That behavior shouldn't occur on a vanilla installation of either 3.15.x version unless there’s a version mismatch or customizations applied to the module. If you're able to provide reproducible steps, we can take a closer look.

You actually fixed it in the 1.3.0 relaese of this module, so I wasn't wrong :D inheritance will break with any BIC in parent module..

@thomas-kl1 thomas-kl1 closed this Sep 1, 2025
@cammonro
Copy link
Contributor

cammonro commented Sep 2, 2025

Thank you for the update @thomas-kl1 ! This is very helpful feedback.

We hadn't officially released 3.16.0 yet so that helps to understand what was going on here. We're going to put more restrictive version requirements in our Composer dependencies here to avoid this in the future.

And yes I agree - the constructor thing is super annoying which is why we want to get away from this approach. Cheers!

cc @damcou

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants