Defined tokens - feature request

[alanlit]

When creating a callback my client has to wait to receive the token (so it can possibly cancel later). If I could supply the token in the setup call, I would not have to wait.(Of course there might be race conditions if I try to cancel quickly, or the setup call might fail - but both of these I would handle on my end). Note that since you cancel by supplying both the original URL and the token this would cause no problems if two independent clients supplied the same token, and likewise if my client supplied a duplicate live token I would just handle some error return.

My use case can involve the wholesale creation of lots of callbacks for lots of users and getting the setup off the user's thread would be really useful.

Thoughts ?

Alan

[BrianMullin]

I can understand your use case, but there are some architectural and security issues that make inverting the source of the CallbackId difficult.

The token that you receive when scheduling a task serves a security function in conjunction with the cancellation process. The Revalee Service (the server process) would be vulnerable to unauthorized cancellation requests without verifying that the caller has possession of the original token.

What we have done in these situations is to allow all of the originally requested callbacks to fire (no cancellations). The callback handler then determines the state of the callback request when it is called on a different thread. The CallbackUrl has parameters that we would use to lookup whether the task should still be processed or should be skipped. This method allows the Revalee workflow to operate in its highest performance use case, while also avoiding race conditions between the cancellation request and the pending callback.