### Description
I am looking at how to properly handle a problem with duplicate ACC
This is when `TMCB_ON_FAILURE` and `TMCB_RESPONSE_OUT` are both called, they are not using the same version of the message. `TMCB_ON_FAILURE` is using the cloned version `TMCB_RESPONSE_OUT` is using the original version
They are not sharing the message flags and 2 ACC events are generated.
Since this is very sensitive, I want to make sure I can trace the real root cause. Not sure if this is a regression ...
#### Reproduction
Any failed call
#### Debugging Data
``` 0(4603) NOTICE: acc [acc_logic.c:686]: tmcb_func(): acc callback called for t(0x7f768b6dac08) event type 2, reply code 404 reqmsg[0x7f768b6dc840] rplmsg[0x7f76d096dee8] 0(4603) ERROR: acc [acc_logic.c:697]: tmcb_func(): [TMCB_RESPONSE_IN][0x7f768b6dc840][0x7f76d096dee8]
// reply route execution
0(4603) ERROR: <core> [core/sip_msg_clone.c:504]: sip_msg_shm_clone(): sip_msg_shm_clone[0x7f768b6dc840]>>[0x7f768b6de738] 0(4603) NOTICE: acc [acc_logic.c:686]: tmcb_func(): acc callback called for t(0x7f768b6dac08) event type 128, reply code 404 reqmsg[0x7f768b6de738] rplmsg[0x7f76d096dee8] 0(4603) ERROR: acc [acc_logic.c:694]: tmcb_func(): [TMCB_ON_FAILURE] run on_missed [0x7f768b6de738][0x7f76d096dee8] // working with the cloned message 0(4603) ERROR: <core> [core/flags.c:59]: isflagset(): isflagset[0x7f768b6de738] 0(4603) ERROR: acc_json [acc_json_mod.c:189]: acc_json_send_request(): missed call flag [7] for this transaction [on]
// failure route execution, we are working with the cloned message 0(4603) NOTICE: <script>: [FAILURE] 0(4603) ERROR: <core> [core/flags.c:46]: setflag(): setflag[0x7f768b6de738] // failure
0(4603) NOTICE: acc [acc_logic.c:686]: tmcb_func(): acc callback called for t(0x7f768b6dac08) event type 512, reply code 404 reqmsg[0x7f768b6dc840] rplmsg[0x7f76d096dee8] 0(4603) ERROR: acc [acc_logic.c:689]: tmcb_func(): [TMCB_RESPONSE_OUT][0x7f768b6dc840][0x7f76d096dee8] // working with the original message 0(4603) ERROR: <core> [core/flags.c:59]: isflagset(): isflagset[0x7f768b6dc840] 0(4603) ERROR: acc_json [acc_json_mod.c:189]: acc_json_send_request(): missed call flag [7] for this transaction [on] ```
just a little update, I this should be handled properly since the flags should be kept even if modified by a transaction callback, good now I need to find out why this is not taking place. ``` /* if failure handler changed flag, update transaction context */ shmem_msg->flags = faked_req->flags; ```
I found consufion about using the integer value of the flag when checking it.
acc_run_engines ``` if((type==1) && (msg->flags&(e->missed_flag))) { ``` and is_eng_acc_on ``` if(msg->flags & e->missed_flag) { ```
However when we reset it we use the bit position value ``` reset_acc_flag( req, flags_to_reset ); #define reset_acc_flag(_rq,_flag) (resetflag((_rq), (_flag))) ```
Looking at this further
Commenting about the third topic directly in this issue. I don't understand this remark: "However when we reset it we use the (bit position value)" ``` reset_acc_flag( req, flags_to_reset ); #define reset_acc_flag(_rq,_flag) (resetflag((_rq), (_flag))) ``` The function resetflag is defined in a similar logic as setflag: struct sip_msg* msg, flag_t flag. And flag_t is defined (as you correctly identified) as unsigned int.
Should be fixed by pull request #1674
Closed #1673.