What is the bug?
Similar to issue #348 looks like since the changes from #335 (2.4.4 release), the document ID is being double-encoded.
How can one reproduce the bug?
Consider an id with URL encoded string such as :
$openSearchClient->create([
"id" => "123:hello-world",
"index" => "some_index",
]);
// "_id": "123%3Ahello-world" the colon is store as encoded `%3A`
vs manually calling OpenSearch API
curl -X PUT http://test.test:9200/some_index/_doc/123:hello-world \
-H "Content-Type: application/json"
This will create document as expected with _id: "123:hobnobs"
What is the expected behavior?
The document ID should not be store as encoded value
What is your host/environment?
Mac OS X 26.0.1, Laravel 12.36.1, opensearch-php 2.4.5
Do you have any screenshots?
N/A
Do you have any additional context?
Looks like the ID get encoded initially in AbstractEndpoint::setId()
|
$this->id = urlencode($docID); |
And then again in corresponding endpoint classes for example Create endpoint.
|
return '/' . rawurlencode($index) . '/_create/' . rawurlencode($id); |
What is the bug?
Similar to issue #348 looks like since the changes from #335 (2.4.4 release), the document ID is being double-encoded.
How can one reproduce the bug?
Consider an id with URL encoded string such as
:vs manually calling OpenSearch API
curl -X PUT http://test.test:9200/some_index/_doc/123:hello-world \ -H "Content-Type: application/json"This will create document as expected with
_id: "123:hobnobs"What is the expected behavior?
The document ID should not be store as encoded value
What is your host/environment?
Mac OS X 26.0.1, Laravel 12.36.1, opensearch-php 2.4.5
Do you have any screenshots?
N/A
Do you have any additional context?
Looks like the ID get encoded initially in
AbstractEndpoint::setId()opensearch-php/src/OpenSearch/Endpoints/AbstractEndpoint.php
Line 147 in 185f791
And then again in corresponding endpoint classes for example Create endpoint.
opensearch-php/src/OpenSearch/Endpoints/Create.php
Line 42 in 185f791