Log elasticsearch issues in any case

[JoshuaBehrens]

1. Why is this change necessary?

When you run in prod mode and have an elastichsearch falling back to database search you don't know why because neither a log message is logged or an exception is thrown.

2. What does this change do, exactly?

Log in any case of an exception before environment evaluation is done.

3. Describe each step to reproduce the issue or behaviour.

1. Use plugins that extend elasticsearch queries
2. Have a slow page or weird behaviour when enabling elastic based search
3. No hints in the log files

4. Checklist

Is there a legit way how to test it when the first check literally is: am I in a test?

• I have written tests and verified that they fail without my change
• I have squashed any insignificant commits
• I have created a changelog file with all necessary information about my changes
• I have written or adjusted the documentation according to my changes
• This change has comments for package types, values, functions, and non-obvious lines of code
• I have read the contribution requirements and fulfil them.

[JoshuaBehrens]

I'll add a changelog file later

[JoshuaBehrens]

Is there a legit way how to test it when the first check literally is: am I in a test?

For real? Shouldn't the first be a mock or decorator doing exactly this?

[shyim]

@JoshuaBehrens You mean with testing? You can construct the class by own and pass a mock to test it

[JoshuaBehrens]

@shyim I mean why is there an env check on 'test'? This should not be code within this namespace, right?

[shopwareBot]

Hello,

thank you for creating this pull request.
I have opened an issue on our Issue Tracker for you. See the issue link: https://issues.shopware.com/issues/NEXT-16905

Please use this issue to track the state of your pull request.

[NiklasLimberg]

I'll mark this as incomplete as long as there isn't a changelog file

[NiklasLimberg]

Hi @JoshuaBehrens,
please write a quick changelog for this and make sure to include the ticket number

[JoshuaBehrens]

I added a changelog. Reading that changelog makes me think: do we want to rename logOrThrowException to tryToThrow? I mean logging is not an optional case anymore

[shopwareBot]

Hello,

thank you for creating this pull request.
I have opened an issue on our Issue Tracker for you. See the issue link: https://issues.shopware.com/issues/NEXT-17334

Please use this issue to track the state of your pull request.

[NiklasLimberg]

well this was already imported to jira hmmmm

[JoshuaBehrens]

@NiklasLimberg which one shall I reference in the changelog?

[NiklasLimberg]

@JoshuaBehrens Ideally NEXT-16905, i've closed the otherone as a duplicate already

[JoshuaBehrens]

I rebased, refactored the helper into an abstract one, aliased the service id, changed changelog. Can you tell me that it was ok to not pull setEnabled into the contract? This isn't needed anyway when #1821 is resolved, right?

@mitelg did I do that correctly?

[shopwareBot]

Hello,

thank you for creating this pull request.
I have opened an issue on our Issue Tracker for you. See the issue link: https://issues.shopware.com/issues/NEXT-17664

Please use this issue to track the state of your pull request.

[NiklasLimberg]

Just disregard the new issue, I forgot again that it already has an issue

[shyim]

As we discussed on Slack, remove the abstract class 👍

[JoshuaBehrens]

I rebased and amend by consensus

[NiklasLimberg]

Hi @JoshuaBehrens,
i've imported this aswell again @shyim will review it once he is back from vacation next week

[shyim]

Thanks for your contribution