lorenzodonini / ocpp-go

Open Charge Point Protocol implementation in Go
MIT License
277 stars 126 forks source link

Allow retrieving ocpp handler #298

Open andig opened 2 months ago

andig commented 2 months ago

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

lorenzodonini commented 1 month 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?

andig commented 1 month ago

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.