Fixed 'transport_name' option resolver check in QueueInteropTransport

[ekkinox]

Fixed 'transport_name' option resolving.

See related issue: https://github.com/sroze/messenger-enqueue-transport/issues/81

[Steveb-p]

It should work without those additional declared transport_name options in all other tests, so they didn't really need to be specified (and I don't feel that this new test adds value, other tests without those options would check that it still works implicitly), but overall :+1:

[ekkinox]

It should work without those additional declared transport_name options in all other tests, so they didn't really need to be specified (and I don't feel that this new test adds value, other tests without those options would check that it still works implicitly), but overall 👍

If you check https://github.com/symfony/framework-bundle/commit/5205108743c2c9063d88d4362137ca60109adf96, 'transport_name' will be added automatically each time from 4.3.3, therefore I updated tests reflecting reality

agree on the new test, maybe a bit overkill just to show that it does not fail without 'transport_name' provided :)

[Steveb-p]

I you check symfony/framework-bundle@5205108, 'transport_name' will be added automatically each time from 4.3.3, therefore I updated tests reflecting reality

On second thought yes, you're right, Symfony will be adding it so it should be checked that it properly "works" when passed :yum:

[chq81]

@sroze Any idea when you are able to merge it? I am desperately waiting for the fix :)

[Steveb-p]

@sroze Any idea when you are able to merge it? I am desperately waiting for the fix :)

@chq81 You can use composer's ability to overwrite package repositories to use your own fork with patch applied until this one is merged.

https://getcomposer.org/doc/05-repositories.md#loading-a-package-from-a-vcs-repository

There are a few use cases for this. The most common one is maintaining your own fork of a third party library. If you are using a certain library for your project and you decide to change something in the library, you will want your project to use the patched version. If the library is on GitHub (this is the case most of the time), you can simply fork it there and push your changes to your fork. After that you update the project's composer.json. All you have to do is add your fork as a repository and update the version constraint to point to your custom branch. In composer.json, you should prefix your custom branch name with "dev-". For version constraint naming conventions see Libraries for more information.

So, in your case it might be:

{
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/chq81/messenger-enqueue-transport"
        }
    ],
    "require": {
        "sroze/messenger-enqueue-transport": "^0.3.2 | dev->>BRANCH-NAME<<"
    }
}

Adding ^0.3.2 will allow you to update to a newer version once it's available (by using composer update sroze/messenger-enqueue-transport), if you have prefer-stable:true in composer.json config (https://getcomposer.org/doc/04-schema.md#prefer-stable)

[mitelg]

I'm also interested in getting this fixed :+1: Currently this prevents us from updating to Symfony 4.3.3 in https://github.com/shopware/platform

[chq81]

@Steveb-p Thank you very much for the detailed instructions.

[ekkinox]

I'm also interested in getting this fixed 👍 Currently this prevents us from updating to Symfony 4.3.3 in https://github.com/shopware/platform

yeah, on our side we froze to 4.3.2 for symfony/framework-bundle waiting for this to be merged

[sroze]

Thank you @ekkinox!