Open andig opened 2 months ago
I'm fine with merging this, but I'm not entirely convinced of the purpose of this feature. Retrieving a request handler at runtime allows to then invoke it arbitrarily:
handler(someWebsocket, requestObj, "dummyID", "BootNotification")
But this would break the library's flow, as you would be invoking your own application's callback without a message actually coming in. This may be harmless for the request handler but can lead to unexpected behavior for the response handler (there's state involved).
If this is only for testing purposes I would rather work on providing a cleaner methodology/API for this purpose.
Or am I misunderstanding this?
But this would break the library's flow, as you would be invoking your own application's callback without a message actually coming in.
Agreed. Our purpose is really specific: we're using this solely for testing a CP not responding to a particular kind of message (which we're observing in reality):
func (suite *ocppTestSuite) TestTimeout() {
// 1st charge point- remote
cp1, ocppjClient := suite.startChargePoint("test-4", 1)
suite.Require().NoError(cp1.Start(ocppTestUrl))
suite.Require().True(cp1.IsConnected())
handler := ocppjClient.GetRequestHandler()
ocppjClient.SetRequestHandler(func(request ocppapi.Request, requestId string, action string) {
if action != core.ChangeAvailabilityFeatureName {
handler(request, requestId, action)
}
})
// 1st charge point- local
_, err := NewOCPP("test-4", 1, "", "", 0, false, false, ocppTestConnectTimeout)
suite.Require().NoError(err)
}
In that case our implementation must not go into error state. If there is another way of testing this we could switch.
Proposed changes
Refs https://github.com/lorenzodonini/ocpp-go/issues/294. This PR allows developing custom handlers without having to reimplement the entire default handler.
Types of changes
What types of changes does your code introduce?
Checklist