A prefix search_near() call is a search_near() call configured with cursor configuration as prefix_key=true. The configuration allows the search_near() to exit early when the search reaches a key that is lexicographically greater than the intended set key.
Prefix search_near() function calls become useful when keys are not all visible to the transaction. For example, in a table of keys ranging from "aaa" - "zzz" of timestamp 50, and the search_near() of key "aa" operates on a timestamp 25. A normal search_near() function would traverse all keys in the tree, to return WT_NOTFOUND. When prefix_key=true is configured, the search_near() function will only look at key ranges in the tree from "aaa" - "aaz", reducing the number of traversals needed to return back WT_NOTFOUND.
Steps to reproduce the issues:
Insert keys "aaa" - "aay" with timestamp 200
Insert key "aaz" with timestamp 50
Call search_near() with key "az", timestamp 100 (see problem 1)
Call search_near() with key "aaza", timestamp 100 (see problem 2)
With a transaction of read timestamp 100, search_near() for the key "az". The expected behaviour is WT_NOTFOUND, since there are no keys that match the prefix "az". However, the current output is returning back the closest visible entry "aaz". From looking at the code:
The valid variable indicates if the cursor positioned by cursor_row_search is a valid entry. If so, the search_near returns back what the cursor is positioned on. In our case, the cursor is positioned on the key "aaz" after the call to cursor_row_search, which is a valid entry. However, it does not match the prefix key.
With a transaction of read timestamp 100 and a search_near() call on a longer prefix "aaza", the expected behaviour is WT_NOTFOUND since there are no keys that have the same prefix "aaza". However, the current output is returning back the closest visible entry "aaz".