I am wondering if something like the below is possible. After some local testing it seems like the timer boundary event is completely getting ignored for this http-connector task. Is this boundary event not compatible with my task?
What exactly is your expectation here?
The service task will be executed directly, so when should your boundary event be triggered? It’s not working like a timeout on your http request, if that’s you expectation.
Yeah I guess that was the expectation. Something like, trying to hit an endpoint, and if that endpoint would normally timeout in 60s lets say, we have a timer event for 20s and it follows the timeout path after the 20s if it has not gotten a response by then. But your saying that it wont work like that for connector tasks yeah?
I’m not totally sure about it, but I think the timer event won’t be triggered while the service task is still executing. I’ve never seen it being used on a service task like this.
Normally I see it used on user tasks or subprocesses.
I do not know how the connector handles timeouts.
I can tell you that in testing this it seemed to just ignore the timer. I made an endpoint that just waited for 20s and return success with a timeout of 10s and it did nothing. I changed up the values all sorts of different ways and still no change in behavior.
And this is fine, not a huge deal for what we are building. I was just wondering if this is how its supposed to work or not.
One could also wrap the service task in a subprocess and put the boundary event on it. But it would be too much for such a simple thing.
There is one more thing to consider. No boundary event can interrupt a running service task (it’s thread). I.e. its action will still be performed. The process job will be rolled back eventually, but the call (if the task calls an external system) will be completed.