Major Description
When testing the REST API there is a corner case where if a user expects to do an update on an existing index and alters the sourceUUID in the index payload a REST update reports success and then subsequently deletes the index. The correct behaviour I believe would be to reject the update.
Steps to reproduce (I used the OnPrem UI):
1. Create a Search Index anmed "a".
2. Copy the definition form the UI's Index Definition Preview and past it into a file "a.orig.json"
3. Look at some key settings only sourceUUID matters
$ cat a.orig.json | jq .uuid
|
"39d993cf10acc6e4"
|
|
|
$ cat a.new.json | jq .sourceUUID
|
"aa2d20faefa62c44504ffaa25d1adb25a6"
|
4. Now update the sourceUUID that match (I add "aa" as a prefix) in the file a.json via vi sed
$ sed -e 's/2d20faefa62c44504ffaa25d1adb25a6/aa2d20faefa62c44504ffaa25d1adb25a6/' a.orig.json > a.new.json
|
5. Verify the change.
$ cat a.orig.json | jq .sourceUUID
|
"2d20faefa62c44504ffaa25d1adb25a6"
|
|
|
diff a.orig.json a.new.json
|
52c52
|
< "sourceUUID": "2d20faefa62c44504ffaa25d1adb25a6",
|
---
|
> "sourceUUID": "aa2d20faefa62c44504ffaa25d1adb25a6",
|
6. Now upload the new definition with the bad sourceUUID into the cluster via REST
$curl -s -XPUT -H "Content-Type: application/json" -u ${CB_USERNAME}:${CB_PASSWORD} http://localhost:8094/api/index/a -d @./a.new.json
|
{"status":"ok","uuid":"1f3e215459fce80f"}
|
Above we see success, but then the UI doc count drops to ZERO and if we leave and return to the search screen the index "a" has been deleted.
The correct behaviour +I believe would be to reject the update with an appropriate error message:+
"error" "rest_create_index: error creating index: a, err: manager_api: sourceUUID does not match the sourceName, current index sourceUUID: 2d20faefa62c44504ffaa25d1adb25a6, does not match the sourceName: travel-sample"
"status": "fail"