track specific calls/callbacks

CaseyBrown

I have an esri.tasks.QueryTask that sends multiple requests to an ArcGIS Server service, which in turn calls the callback function upon completion.  (configured using the QueryTask's onComplete property)

Is there any good way to correlate which calls to my QueryTask's execute function correspond to which callbacks?  Here's a hypothetical situation I'd like to have a good solution for:

A user makes a request for, say, the nearest 300 points to a particular object and submits it.  The QueryTask sends the request to the server, which takes a non-trivial time (say 15 seconds) to process.  In the meantime, the user decides he only wants 10 points, so he tells my app to cancel the first request and make a different one instead.  The QueryTask sends off this second request before the first one is received.

What I would like is a way to differentiate between the requests when the results are received by my callback function.  In the example above, I want to be able to ignore the first request but process the second (realizing that either one could arrive back before the other).

The only thing that I can think of is to pass a piece of identifying information to the server and have it echo it back in its response.  However, this might not work for me as I likely can't alter the server's response (and, for that matter, I'm not sure how to make the QueryTask pass along such info.  I guess I could replicate QueryTask on my own and add that ability but...why reinvent the wheel if I don't need to?).

Thanks for any ideas you have,

-Casey

SteveMarkovick

This question resonates with some of the asynchronous tracking challenges we’ve faced outside of GIS. While dojo.Deferred is great for managing callbacks, attaching a unique identifier (like a timestamp or request ID) to each QueryTask call on the client side and maintaining a map of promises keyed to those IDs has worked well for us. In lead tracking systems like Phonexa, every call, click, and form submission is linked to a unique journey ID—it’s that kind of traceability that ensures we only act on relevant data, even when responses arrive out of order. Might be worth adopting a similar pattern for your spatial queries too.