Able to Stop an OCPP Transaction Multiple Times with Different Meter Values

[Tano-Coppoletta]

Checklist

• [ ] I checked other issues already, but found no answer/solution
• [x] I checked the documentation and wiki, but found no answer/solution
• [ ] I am running the latest version and the issue still occurs
• [x] I am sure that this issue is about SteVe (and not about the charging station software or something unrelated to SteVe)

Specifications

SteVe Version     : 3.6.0
Operating system  : Ubuntu 22.04.1
JDK               : openjdk version "11.0.20.1"
Database          : version 1.0.3

Expected Behavior

The system should enforce transaction integrity by only allowing a single StopTransaction message for each StartTransaction. Any additional StopTransaction messages for a transaction that has already been stopped should be rejected to prevent duplicate entries in the database.

Actual Behavior

Multiple StopTransaction messages are accepted by the system for a single transaction, which results in multiple stop records for the same transaction in the transaction_stop table. This behavior leads to inconsistencies and potential errors in transaction management and reporting.

Steps to Reproduce the Problem

1. Send a StartTransaction message:

   [2,"1","StartTransaction", {
     "connectorId": 2,
     "idTag": "6",
     "meterStart": 2,
     "reservationId": 11,
     "timestamp": "2023-10-03T12:34:56Z"
   }]
   

2. Send a StopTransaction message multiple times for the same transaction, with varying meterStop values:

   [2,"1","StopTransaction", {
     "idTag": "6",
     "meterStop": 200,
     "timestamp": "2023-11-06T15:54:23Z",
     "transactionId": 676897,
     "reason": "EVDisconnected"
   }]
   

   (Repeat this step with different meterStop values and/or reason values)
3. Observe that each StopTransaction message creates a new entry in the transaction_stop table for the same transaction_pk.

Additional context

The screenshot represent the state of the database after sending two different StopTransaction messages, one with meterStop = 0 and another one with meterStop = 1000

[goekay]

this is by design.

some time ago we added the functionality to manually stop "ghost" transactions in the web UI (i.e. transactions that are open for a really long time because probably the station forgot to close them. in these cases, subsequent transactions even exist for the same station and connector). these ghost transactions are stopped by inserting a StopTransaction event with some workarounds to determine the stop timestamp and value.

but, what if the user was too eager and impatient and stopped this transaction? therefore, when implementing this feature, i did not want to take away the possibility of the station to "correct" this StopTransaction later. therefore, multiple StopTransactions are allowed. we take the latest one when reporting.