steve
steve copied to clipboard
Able to Stop an OCPP Transaction Multiple Times with Different Meter Values
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
- Send a
StartTransaction
message:[2,"1","StartTransaction", { "connectorId": 2, "idTag": "6", "meterStart": 2, "reservationId": 11, "timestamp": "2023-10-03T12:34:56Z" }]
- Send a
StopTransaction
message multiple times for the same transaction, with varyingmeterStop
values:
(Repeat this step with different[2,"1","StopTransaction", { "idTag": "6", "meterStop": 200, "timestamp": "2023-11-06T15:54:23Z", "transactionId": 676897, "reason": "EVDisconnected" }]
meterStop
values and/orreason
values) - Observe that each
StopTransaction
message creates a new entry in thetransaction_stop
table for the sametransaction_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
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.