Browse code

bug_fix: after return from on_negative_reply, UAS reply code is checked first prior to proceeding to introducing new branches

Jiri Kuthan authored on 18/09/2002 21:41:25
Showing 1 changed files
... ...
@@ -715,6 +715,22 @@ enum rps t_should_relay_response( struct cell *Trans , int new_code,
715 715
 		   a callback
716 716
 		*/
717 717
 		callback_event( TMCB_ON_NEGATIVE, Trans, 0, lowest_s );
718
+		/* look if the callback perhaps replied transaction; it also
719
+		   covers the case in which a transaction is replied localy
720
+		   on CANCEL -- then it would make no sense to proceed to
721
+		   new branches bellow
722
+		*/
723
+		if (Trans->uas.status >= 200) {
724
+			*should_store=0;
725
+			*should_relay=-1;
726
+			/* this might deserve an improvement -- if something
727
+			   was already replied, it was put on wait and then,
728
+			   returning RPS_COMPLETED will make t_on_reply
729
+			   put it on wait again; perhaps splitting put_on_wait
730
+			   from send_reply or a new RPS_ code would be healthy
731
+			*/
732
+			return RPS_COMPLETED;
733
+		}
718 734
 		/* look if the callback introduced new branches ... */
719 735
 		init_branch_iterator();
720 736
 		if (next_branch(&dummy)) {
... ...
@@ -733,18 +749,6 @@ enum rps t_should_relay_response( struct cell *Trans , int new_code,
733 749
 			*should_relay=-1;
734 750
 			return RPS_STORE;
735 751
 		}
736
-		/* look if the callback perhaps replied transaction */
737
-		if (Trans->uas.status >= 200) {
738
-			*should_store=0;
739
-			*should_relay=-1;
740
-			/* this might deserve an improvement -- if something
741
-			   was already replied, it was put on wait and then,
742
-			   returning RPS_COMPLETED will make t_on_reply
743
-			   put it on wait again; perhaps splitting put_on_wait
744
-			   from send_reply or a new RPS_ code would be healthy
745
-			*/
746
-			return RPS_COMPLETED;
747
-		}
748 752
 		/* really no more pending branches -- return lowest code */
749 753
 		*should_store=0;
750 754
 		*should_relay=lowest_b;