-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unhandled json errors in GetConfiguration #234
Comments
Looking at the code it seems the message goes through
which will return the json error. It looks as if the error somehow might get swallowed inside
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 evcc-io/evcc#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:
The text was updated successfully, but these errors were encountered: