Strange state transaciton handling

[shengxiang200788]

Hi matth-x I got a lastest tx, its content is : {"session":{"active":false,"idTag":"123456","authorized":true,"timestamp":"2024-06-26T10:08:26.896Z"},"start":{"requested":true,"meter":198,"timestamp":"2024-06-26T10:08:26.925Z","bootNr":11,"transactionId":185},"stop":{"requested":true,"idTag":"123456","meter" :198,"timestamp":"2024-06-26T10:08:47.778Z","bootNr":11}}

after reboot the ocpp, and try to do charging, I got: tx process still running. Please call endTransaction(...) before

Seems that the previous tx still ocuppy the connector. I checked the tx content, its start request is true, conf is false, stop request is true, conf is false. this kind of tx is hard to reproduced, a bad network may trigger the situation.

And I checked the connector.cpp, after initialized, connector.cpp loop() will run into : if (!transaction->isRunning()) { //start tx? .... } and do nothing to the tx because its active is false.

And the isRunning() is defined as bool isRunning() {return start_sync.isRequested() && !stop_sync.isRequested();} this seems not so good for real enviroment, a tx is stop requested maybe dealed as no running, and maybe need a restarting.

[shengxiang200788]

Think that a stop requested tx should be handled seperately from !isRunning() and isRunning(). A !isRunning tx could be a stopped tx that should be removed.

[matth-x]

Hi @shengxiang200788,

Thanks for the report and your analysis. There's indeed been a recent issue on stale transactions blocking the connector, but I hoped that would be resolved. Are you on version 1.1?

Another possibility is that the Connector object didn't have a chance yet to clean it's transaction member. During initialization, Connector always loads the most recent transaction and after that, during the first main-loop iteration (and all following), it decides whether this transaction is stale or not. See the logic here:

https://github.com/matth-x/MicroOcpp/blob/8b1f0fdbae8785c49453f0b2d54a1a8db2fbe3ed/src/MicroOcpp/Model/ConnectorBase/Connector.cpp#L229-L232

So the Connector::loop() function needs to be executed at least once after startup to start a new transaction. That happens during the first mocpp_loop() call if the configuration Cst_PreBootTransactions is true, or if the charger received a BootNotification.conf with registration status Accepted.

If this doesn't resolve the issue, I will reconstruct the error scenario with your transaction JSON file.

[shengxiang200788]

I forget to tell that，during the test，i send local list to cp，and used the idtag in the list

[shengxiang200788]

Hi @shengxiang200788,

Thanks for the report and your analysis. There's indeed been a recent issue on stale transactions blocking the connector, but I hoped that would be resolved. Are you on version 1.1?

Another possibility is that the Connector object didn't have a chance yet to clean it's transaction member. During initialization, Connector always loads the most recent transaction and after that, during the first main-loop iteration (and all following), it decides whether this transaction is stale or not. See the logic here:

https://github.com/matth-x/MicroOcpp/blob/8b1f0fdbae8785c49453f0b2d54a1a8db2fbe3ed/src/MicroOcpp/Model/ConnectorBase/Connector.cpp#L229-L232

So the Connector::loop() function needs to be executed at least once after startup to start a new transaction. That happens during the first mocpp_loop() call if the configuration Cst_PreBootTransactions is true, or if the charger received a BootNotification.conf with registration status Accepted.

If this doesn't resolve the issue, I will reconstruct the error scenario with your transaction JSON file.

Test is based on V1.0.3, will try V1.1.0

[shengxiang200788]

V1.1.0 tried, ocpp run into these lines:

                //no, end of history reached, don't delete further tx
                MO_DBG_DEBUG("cannot delete more tx");

The previous obsolete transaction is not deleted, new tx alloc failed.

[matth-x]

Does this happen while the charger is online? If yes, do you have the possibility to view all the JSON files? The files starting with "op" (opstore.json and op-XXX.jsn) and "tx" (txstore.jsn and tx-XXX.jsn) would very helpful for further diagnosis.

Otherwise I would recommend clearing the local state after the FW upgrade. MO clears the transaction "cache" when you send it the ClearCache command.

[shengxiang200788]

Does this happen while the charger is online? If yes, do you have the possibility to view all the JSON files? The files starting with "op" (opstore.json and op-XXX.jsn) and "tx" (txstore.jsn and tx-XXX.jsn) would very helpful for further diagnosis.

Otherwise I would recommend clearing the local state after the FW upgrade. MO clears the transaction "cache" when you send it the ClearCache command. I'm sorry that I'v lost the tx json files,