Open andig opened 1 year ago
Looking at the code it seems the message goes through
profile.ParseResponse
which will return the json error. It looks as if the error somehow might get swallowed inside
server.ocppMessageHandler
but I'm not sure how that would happen.
Not sure that is what we're seeing, but if cp response contains a valid messages id- what it does- cs tries to respond:
// Send error to other endpoint if a message ID is available
if ocppErr.MessageId != "" {
err2 := s.SendError(wsChannel.ID(), ocppErr.MessageId, ocppErr.Code, ocppErr.Description, nil)
if err2 != nil {
return err2
}
}
log.Error(err)
return err
If that response fails we will never see the original error (which is unfortunate).
That is not the case here though. Why don't we see the error returned?
@lorenzodonini any idea why the error is never returned? Do you have an idea how a test for this behaviour could look like?
In https://github.com/evcc-io/evcc/issues/10339 we've noticed that
GetConfiguration
requests to charger timed out:At the same time, we can see that the answer is actually received. Unfortunately, it turns our that the answer is wrong since
readonly
is encoded as string:Although we are listening for the
Errors()
channel, no error is logged. The issue here is that- apart from vendor ignoring the spec- is that the JSON decode error that must have happened is not returned/raised/logged. Extending theTestGetConfigurationConfirmationValidation
confirms that:This should fail but doesn't: