Closed lategoodbye closed 5 years ago
hmm. thanks for using the template and reporting this issue in a very detailed manner!
failing upon receiving unknown transcation id is a known problem. i just don't know what a good workaround should be. we sure can always respond with a stop transaction conf. but then we start to swallow exceptions/problems which might go unnoticed and cause bigger problems afterwards.
in addition to that, in order to prevent information loss i also considered another database table (something like transaction_stop_unknown
, in which we just insert the sent values without constraint checks and references to other tables), but i don't know how good of a solution this is.
Personally, i don't have a problem with the exception as long as the StopTransaction.Conf is send.
yeah but we also have to think about its side effects in the big picture.
start transaction is in the same situation as well: steve must always respond with a start transaction conf. this might be problematic, since the transcation id
might not be generated. something like -1
as place holder? how to differentiate between multiple -1
transactions? we cannot use something like UUID since the field is an integer. then... we probably need a transaction_start_unknown
table to insert invalid data as well. how should the user (of steve, the station manager if you will) match start and stop events of invalid (-1
) transactions?
Even worse, i didn't find a clear definition of transaction id
except of integer. At least in OCPP 2.0 it is defined as signed 32 bit. But i didn't find a statement, what clarifies what is a valid transaction or not.
StopTransaction processing should be exception free now. we catch all exceptions and log them. a confirmation is always sent back. however, i still have to figure out solutions for 1) the StartTransaction and 2) what to do with the data to prevent information loss.
still have to figure out solutions for 1) the StartTransaction and 2) what to do with the data to prevent information loss.
here is my rough thinking regarding 1: after looking at the processing of StartTransaction, i realized that there is very little that might go wrong, because we work around problematic cases already. if the connectorId
and idTag
properties are new and unknown, we insert them already. theoretically, an exception (for whatever reason) might still occur, but i don't want to touch such a case right now.
regarding 2: as i illustrated, i plan to insert failed transaction_stop
insertions into another table transaction_stop_unknown
that is column-wise similar to transaction_stop
minus the constraints and foreign key references. i don't want to make this table in web ui available. users should just look at the database table for further analysis.
i hope this roadmap is okay for everyone.
Checklist
Specifications
Expected Behavior
In case an OCPP 1.6 client sends a StopTransaction.Req with an unknown transaction id:
[2,"d51884d53448aa9ec78738dbafb76c8b2159","StopTransaction",{"meterStop":140,"reason":"PowerLoss","timestamp":"2019-07-02T09:44:21.530Z","transactionId":0}]
SteVe should reply with a StopTransaction.Conf (according to OCPP 1.6 spec, chapter 4.10).
Actual Behavior
SteVe triggers SQLIntegrityConstraintViolationException
and replies with an InternalError : Internal services failed while processing of the payload which causes the OCPP client to repeat the StopTransaction.Req
Steps to Reproduce the Problem
Note: This isn't a regression also SteVe 3.2.0 was effected.