Found while building the Batch/Transaction workspace (#476). Bundle GET entries whose request.url is a search are treated as instance reads in both bundle types:
transaction entry {method: GET, url: "Patient?name=Nguyen"}
→ 400 "Transaction failed at entry N: Entry processing failed: invalid reference: Patient?name=Nguyen"
batch entry {method: GET, url: "Patient?name=GetById"}
→ entry response "404 Not Found" ("Resource not found") — the search URL parsed as a resource address
GET Patient/{id} works in both types (200 with the resource). Per the R4 transaction processing rules, GET entries cover both reads and searches — the entry URL is interpreted "as a request against the server's base", so Patient?name=X should execute the search and return a searchset in that entry's response.
The workspace UI (#476) renders whatever the server answers, so nothing blocks there — but a user uploading a legitimate search-in-bundle gets a confusing failure today.
Found while building the Batch/Transaction workspace (#476). Bundle GET entries whose
request.urlis a search are treated as instance reads in both bundle types:GET Patient/{id}works in both types (200 with the resource). Per the R4 transaction processing rules, GET entries cover both reads and searches — the entry URL is interpreted "as a request against the server's base", soPatient?name=Xshould execute the search and return a searchset in that entry's response.The workspace UI (#476) renders whatever the server answers, so nothing blocks there — but a user uploading a legitimate search-in-bundle gets a confusing failure today.