Passing the response from @on to the @after method

Hello,

I have the following scenario:

    @on(Action.RequestStartTransaction)
    async def on_request_start_transaction(
        self,
        *args,
        **kwargs
    ) -> call_result.RequestStartTransactionPayload:

        response: call_result.RequestStartTransactionPayload = (
            await TransactionHandler.handle_on_request_start_transaction(**kwargs)
        )

        # at this point, the response can be accepted
        # or it can be rejected
        return response


    @after(Action.RequestStartTransaction)
    async def after_request_start_transaction(
        self,
        *args,
        **kwargs
    ) -> call_result.TransactionEventPayload:

        # at this point, I would like to run this method conditionally,
        # only if the response sent back to the CSMS was accepted
        # if it was rejected, I do not want to run this method
        return await TransactionHandler.handle_after_request_start_transaction(**kwargs)

Looking at charge_point.py, it looks like it is the payload from the initial call which is passed into the @after function. What would you think of also passing through the response of the call so that it can be used for further processing?

I have a workaround by using a temp variable, but thought it could be a nice feature of the library so posting here.

[OrangeTux]

The routing system of this library is not very sophisticated and could use some improvement.

In the current implementation, the @on() handler is executed and it’s return value is send as response to the other peer. Next, the @after() handler is executed. The return value of the @after() handler is ignored.

I’m afraid that above process might not be clear to all users of this library. In fact, the code sample that @HugoJP1 seem to indicate that this is not clear for them, as the @after() contains a return statement. Although this return value doesn’t do anything. Don’t get me wrong, that is a fault of the API, not of the users.

Assume for now, return value of the @on() handler is passed down to the @after() handler. Modifying the response and trying return it won’t send the modified response to the other peer. Here a code sample that shows invalid use of the proposed API:

class ChargePoint(cp)
    @on(Action.BootNotification)
    def on_boot_notification(self, charge_point_vendor: str, charge_point_model: str, **kwargs):
        return call_result.BootNotificationPayload(
            current_time=datetime.utcnow().isoformat(),
            interval=10,
            status=RegistrationStatus.accepted
        )
     
    @after(Action.BootNotification)
    def after_boot_notification(self, charge_point_vendor: str, charge_point_model: str, _response: call_result.BootNotificationPayload, **kwargs):
        # Invalid use of the API. This return value won't be send to the charge point.
        _response.interval = 20
       return _response

In retrospect, the current api of @on() and @after() is too limiting. And we could use a better one. Maybe this ticket can serve as a discussion.

One quick proposal, that I didn’t thought through yet is to allow preprocessing of requests,and post-processing of response. E.g.

class ChargePoint
    @on(Action.BootNotification, pre=pre_boot_notification, post=post_boot_notification)
    def on_boot_notification(self, charge_point_vendor: str, charge_point_model: str, **kwargs):
        return call_result.BootNotificationPayload(
            current_time=datetime.utcnow().isoformat(),
            interval=10,
            status=RegistrationStatus.accepted
        )
        
     def pre_boot_notification(self, request: call.BootNotificationPayload) -> call.BootNotificationPayload:
         # Modify request here before it's passed to `@on()` handler.
         return request
    
    def post_boot_notification(self, request: call.BootNotificationPayload, response: call_result.BootNotificationPayload) -> call_result.BootNotificationPayload:
        # Modify response before it's send to peer.
        return response

It might even be made backwards compatible.

[betovaca]

@tropxy Did you manage to do it? If so, can you share an example with us? Thanks