Initially this meant to be just addition of an endpoint, but eventually it exposed quite serious bug in quesma/quesma/router.go.
1. Adding /_async_search/status/:id handling
Before that change, requests targeting this endpoint were routed to Elasticsearch which of course had no recollection of our own async IDs quesma_async_019329bf-4330-7007-970d-e87734bca7c3.
This fixes the following behavior, esp. visible when querying larger data sets:
2. Fixing router.go
The root cause of this bug was in findHandler function of quesma/mux/mux.go. Basically, whenever we registered same route twice with diffrent matchers (e.g. for two separate HTTP methods), findHandler always ditched the second registered func. See screenshot below:
Of course I had to add a pretty large test to make sure I don't break stuff.
pdelewski
commented
1 week ago
Initially this meant to be just addition of an endpoint, but eventually it exposed quite serious bug in
quesma/quesma/router.go.1. Adding
/_async_search/status/:idhandlingBefore that change, requests targeting this endpoint were routed to Elasticsearch which of course had no recollection of our own async IDs
quesma_async_019329bf-4330-7007-970d-e87734bca7c3.This fixes the following behavior, esp. visible when querying larger data sets:
2. Fixing
router.goThe root cause of this bug was in
findHandlerfunction ofquesma/mux/mux.go. Basically, whenever we registered same route twice with diffrent matchers (e.g. for two separate HTTP methods),findHandleralways ditched the second registered func. See screenshot below:Of course I had to add a pretty large test to make sure I don't break stuff.
Closes: https://github.com/QuesmaOrg/quesma/issues/995