Release AddPathPlugin fix in 1.9.x

[garex]

Q	A
Bug?	no
New Feature?	no
Version	1.9.1

Actual Behavior

AddPathPlugin was broken in 1.x and fixed in 2.x branch.

Expected Behavior

AddPathPlugin must be fixed in 1.x branch too.

Steps to Reproduce

Not required.

Possible Solutions

Release AddPathPlugin fix in 1.x branch. For 3rd-party developers fix of this plugin will be simpler than adopting to 2.x. Currently I'm using https://github.com/janephp/open-api-runtime/ which depends to ^1.4.

[garex]

Only drop : Promise and declare(strict_types=1); from it.

[garex]

Currently I need to copy-paste it to my project and this is stone age..

[dbu]

if i remember correctly, we did this only for master because the behaviour changes slightly. i would recommend that you copy the plugin into your application namespace and configure it as a service and register it with the client.

[garex]

David, already did. But its weird. 😱 Changes in master is actual fix of not always working spl hash bug. So its only inner change, that is more bundled to original class contract. Not something back compat break. Pls see semver bible for this. вс, 10 марта 2019 г., 16:07 David Buchmann <notifications@github.com>:

…

if i remember correctly, we did this only for master because the behaviour changes slightly. i would recommend that you copy the plugin into your application namespace and configure it as a service and register it with the client. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#171 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEwnVZ-RDUJIB-pEvQhjRuQgJauzK_Cks5vVMtsgaJpZM4bnGkj> .

[dbu]

i think this is one of those borderline cases where its not a straight up bug fix but a fix that can have a different unexpected behaviour. however, i notice now that we did not label #141 as BC break.

@php-http/httplug how do you think about backporting that fix to version 1? if memory serves me correctly, we started out on 2.0 because we wanted to do that thing with a marker header on the request to know if we already saw the request...
i vote for putting it into 1 as the potential for a surprise is much smaller than the nuisance of long running processes "randomly" not working.

[joelwurtz]

We could also keep the same behavior and only fix the memory bug in 1.x (unsetting the id after response resolution) ?

[dbu]

i think we discussed that option in #141 and realized it also changes the current behaviour. i think if we do change it, we should change it to do the same in 1.9 as in 2.

[Nyholm]

Didn't we decide that if we make any changes to AddPathPlugin we would exclude one use-case. There are no solution that would fix all problems. That is why we left it as it was and recommended people to implement their own AddPathPlugin if their edge case was not covered.

[garex]

@Nyholm which use-case? I think better to have correclty working version, than non-working + suggestion to implement own version.

[mxr576]

I could not figure out a better way either than forking the AddPathPlugin from the 2.x branch ^.