[Cache] fix integration tests #57201
Conversation
xabbuh
commented
May 28, 2024
| Q | A |
|---|---|
| Branch? | 7.1 |
| Bug fix? | no |
| New feature? | no |
| Deprecations? | no |
| Issues | |
| License | MIT |
| @@ -25,7 +25,7 @@ | |||
| <env name="ZOOKEEPER_HOST" value="localhost" /> | |||
| <env name="COUCHBASE_HOST" value="localhost" /> | |||
| <env name="COUCHBASE_USER" value="Administrator" /> | |||
| <env name="COUCHBASE_PASS" value="111111%40" /> | |||
| <env name="COUCHBASE_PASS" value="111111@" /> | |||
There was a problem hiding this comment.
@alexandre-daubois @nicolas-grekas I am not really sure why this is required. Does the CouchbaseCollectionAdapter work differently than the CouchbaseBucketAdapter?
There was a problem hiding this comment.
That was the starting point of #57192 😄
This was changed to ensure that the Couchbase adapter is decoding special chars from password and you're able to put an encoded @ in it. @ is used to separate user:pass from the actual hostname, making it impossible to use the raw value as-is. Special chars decoding is currently done on a case-by-case basis in each DSN adapter parser.
Secondly, why those two classes? If I remember correctly, one of the adapter is deprecated and used for an old version of Couchbase, whereas the other one is the one to use in new application. Those versions are incompatible and only one version is tested in the integration test suite. Otherwise it would require to run two Couchbase instance but that's super complicated (partly because they need different min versions of PHP, among other things).
There was a problem hiding this comment.
Well, the decoding is not necessary in our integration tests as username and password are passed separately and are not part of the DSN. But that was also the case when we ran tests with the CouchbaseBucketAdapter. That's why I wondered if there was another difference which explains why we need this change to make tests pass.
There was a problem hiding this comment.
Not that I can remember 🤔
There was a problem hiding this comment.
I had some hard times debugging this adapter, it is (very) complicated to test on a local machine. The fact it is unstable on the CI makes me wonder even more if this shouldn't be deprecated. The version supported by our adapter is old and no contributions seems planned to bring support for newer versions. I think the question of the deprecation arises.