In order to explain why this is needed, I've prepared a new test scenario: kamailio/kamailio-tests#19

This sees an HTTP request being performed in a reply route, using http_async_client and with suspension of the transaction.
Upon landing into the HTTP reply route, the transaction is suspended for a second time while a new http_async_query() is performed.

Without the change in this PR, the suspension during the second query, even though it's logged as happened, doesn't have effect on t_continue_helper() which continues processing the reply. The reply is so sent out and when the HTTP reply route is reached afterwards the transaction exists but it's already in terminated state.

An example of .cfg (as used in the example test scenario):

request_route {
	if (is_request()) {
		if (is_method("INVITE")) {
			t_newtran();
			t_on_reply("INVITE_REPLY");
			t_relay("127.0.0.1", "5080");
			exit;
		}
		else if (is_method("ACK")) {
			t_relay("127.0.0.1", "5080");
			exit;
		}
	}
	drop;
}

onreply_route[INVITE_REPLY] {
	xlog("L_INFO", "================ INVITE_REPLY ==================\n");
	if (status=~"200") {
		http_async_query("http://127.0.0.1:8080/", "HTTP_REPLY1");
	}
}

route[HTTP_REPLY1] {
	xlog("L_INFO", "================ HTTP_REPLY1 ==================\n");
	if ($http_ok) {
		xlog("L_INFO", "HTTP GET REPLY1: $http_rs - Response: $http_rb\n");
		http_async_query("http://127.0.0.1:8080/", "HTTP_REPLY2");
		sl_send_reply("200", "OK");
		exit;
	}
	else {
		xlog("L_ERR", "HTTP error: $http_err\n");
	}
}

route[HTTP_REPLY2] {
	xlog("L_INFO", "================ HTTP_REPLY2 ================== DONE\n");
}

The debug log before the change:

 6(32) DEBUG: tm [t_lookup.c:1612]: t_lookup_ident_filter(): transaction found
 6(32) DEBUG: http_async_client [async_http.c:235]: async_http_cb(): resuming transaction (44930:409999179)
 6(32) DEBUG: tm [t_lookup.c:1612]: t_lookup_ident_filter(): transaction found
 6(32) DEBUG: tm [t_suspend.c:364]: t_continue_helper(): continuing from a suspended reply - resetting the suspend branch flag

 6(32) INFO: <script>: ================ HTTP_REPLY1 ==================
 6(32) INFO: <script>: HTTP GET REPLY1: 200 - Response:

Now it calls async_send_query():

 6(32) DEBUG: tm [t_suspend.c:113]: t_suspend(): this is a suspend on reply - setting msg flag to SUSPEND
 6(32) DEBUG: tm [t_lookup.c:1034]: t_check_msg(): msg (0x7f48b3cd6b60) id=2/27 global id=2/27 T start=0x7f48b3cd34d8
 6(32) DEBUG: tm [t_lookup.c:1109]: t_check_msg(): T (0x7f48b3cd34d8) already found for msg (0x7f48b3cd6b60)!
 6(32) DEBUG: tm [t_suspend.c:121]: t_suspend(): found a a match with branch id [0] - cloning reply message to t->uac[branch].reply
 6(32) DEBUG: tm [t_suspend.c:133]: t_suspend(): saving transaction data

 6(32) DEBUG: http_async_client [async_http.c:469]: async_send_query(): transaction suspended [44930:409999179]

(index and label are as expected)

 6(32) DEBUG: http_async_client [async_http.c:625]: async_push_query(): query sent [http://127.0.0.1:8080/] (0x7f48b3cdfa08) to worker 1

Here it should have suspended, but it's actually continuing in the reply route:

 6(32) DEBUG: tm [t_suspend.c:408]: t_continue_helper(): restoring previous environment
 6(32) DEBUG: tm [t_suspend.c:435]: t_continue_helper(): t is not local - relaying reply with status code: [200]

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.