Avoid double send of csms_ack_0 transactions

[Matthias-NIDEC]

OCPP Version

OCPP1.6

Describe the bug

In the case a charging process is ongoing, the connection to the backend is disconnected and, later, he charging process is stopped.
It is stored inside the transaction database with csms_ack=0 and the stoptransaction.req is stored inside the transaction_queue.

On boot up, the transaction_queue is emptied and the transactions with csms_ack=0 are resend. If the message_queue is alredy emptied before the check of the open transactions, then the stopTransaction.req is sent again.

In order to avoid that a helper vector with transactionIds in flight is added.

See #906

To Reproduce

No response

Anything else?

No response

[Pietfried]

To reproduce:

• Start tx
• go offline
• stop tx
• reboot

TODO: also consider how OCMF is handled

[Pietfried]

To reproduce:

• Start tx
• go offline
• stop tx
• reboot

TODO: also consider how OCMF is handled

@Matthias-NIDEC I couldnt reproduce it this way? Can you confirm the steps to reproduce or did I miss something?

[Pietfried]

@Matthias-NIDEC do you have an update for this issue?

[Matthias-NIDEC]

@Pietfried
From out site, the point is still open:

One thread t1 executes:
this->message_queue->get_persisted_messages_from_db(this->configuration->getDisableSecurityEventNotifications());
this->boot_notification(); -->
--> inside this->message_dispatcher->dispatch_call here the push_call calls the cv.notify_all() from the MessageQueue.hpp and here a resquedule of the MessageQueue.hpp can happen
Thread change to that one which empties MessageQueue
The t1 returns:
the message queue is empty and the try_resume_transcation is called:

this->try_resume_transactions(resuming_session_ids);
here:
this->message_queue->contains_stop_transaction_message(transaction_entry.transaction_id) is false and the else part happens and executes again stop_transaction