Error Message does not match the OCPP JSON specification. about steve

[goekay]

working on it. can you tell me what caused the exception? maybe there is an issue with handling of meter values?

[JavaIsJavaScript]

I stumbled across this whilst testing MeterValues:

[4,"jKg4ShEDt4PxSv3J4291tioh2ES2K3dV","InternalError","Internal services failed while processing of the payload","SQL [insert into
stevedb.connector_meter_value (connector_pk, transaction_pk, `value_timesta..."]

But this was because i was using a transactionId that was not related to the Charge Point/request, after using a correct transactionId related to the Charge Point/request it just worked perfectly.

This "InternalError" happens aswell if the transactionId sent by the Charge Point in the MeterValues.req does not exist

[goekay]

EDIT: As well as, the entry "errorDetails" should be an object and not a string as the server returns.

@nuno407 i know. my commit fixed this and only this, as i explained in my previous comment

[goekay]

alright.

[nuno407]

Thank you @JavaIsJavaScript.
That's correct!

[goekay]

This "InternalError" happens aswell if the transactionId sent by the Charge Point in the MeterValues.req does not exist

@JavaIsJavaScript are you sure about this? During my tests MeterValues.req without a transaction id do not cause an internal error.

[JavaIsJavaScript]

Yeah, without transactionId works, but if the transactionId in the request doesn't exist in the database i ment

[goekay]

ah okay, then it's not our problem :)

[nuno407]

But @goekay,
The error response still does not match the specification. In this case a "PropertyConstraintViolation" as defined in OCPP-J v1.6 should be throw right?

EDIT: As well as, the entry "errorDetails" should be an object and not a string as the server returns.

"errorDetails": {
    "type": "object"
}

Thank you for the help,
nuno

[goekay]

technically speaking, you are right. i only fixed the bug, that errorDetails was handled as a simple string and not json object. it was there for years and was overlooked.

but the fact, whether a transaction id exists or not, is checked within the database (foreign key constraint). if it does not exist, we get in the application a chain of exceptions: SQLIntegrityConstraintViolationException in BatchUpdateException in DataAccessException. at this point, it's really hard to find out what went why wrong, other than looking at the error string returned by the database.

this is one of the reasons, why we cannot use some of the finer grained error codes.

[nuno407]

Thank you @goekay !