Skip to content
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

Allow retrieving ocpp handler #298

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

andig
Copy link
Contributor

@andig andig commented Sep 14, 2024

Proposed changes

Refs #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?

  • Bugfix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Documentation Update (if none of the other choices apply)

Checklist

  • I have read the CONTRIBUTING doc
  • I have signed the CLA
  • Lint and unit tests pass locally with my changes
  • I have added tests that prove my fix is effective or that my feature works
  • I have added necessary documentation (if appropriate)
  • Any dependent changes have been merged and published in downstream modules

@lorenzodonini
Copy link
Owner

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
Copy link
Contributor Author

andig commented Oct 20, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants