Changed handlers do not handle messages

[valentin-gauthier-geosiris]

What are the steps to reproduce this issue?

I want to download a data_array from a server. The function [session].getDataArray(..) doesn't currently exists. Thus I tried to changed the response handler and wait for a response.
However, my handler seems not catch the response.

To reproduce :

import fesapi
import fetpapi
import uuid
import os
from threading import Thread
from time import sleep, perf_counter
from energyml.utils.introspection import get_class_attributes


class DataArrayHandlers(fetpapi.DataArrayHandlers):

    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)

    def on_GetDataArraysResponse(self, gdar, correlationId):
        r"""on_GetDataArraysResponse(DataArrayHandlers self, GetDataArraysResponse gdar, int64_t correlationId)"""
        print("\nYES")
        print(gdar.dataArrays)


def initiate_fetpapi_sessions(
    url: str, access_token: str, headers: dict
) -> fetpapi.ClientSession:

    if url is not None:
        if "bearer" not in access_token.lower():
            authorization = "Bearer " + access_token
        initialization_params = fetpapi.InitializationParameters(str(uuid.uuid4()), url)

        additionalHeaderField = fetpapi.MapStringString()
        for hk, hv in headers.items():
            additionalHeaderField[hk] = hv
        initialization_params.setAdditionalHandshakeHeaderFields(additionalHeaderField)

        return fetpapi.createClientSession(initialization_params, authorization)

    return None


def start_etp_server(client_session):
    client_session.run()


if __name__ == "__main__":
    # Set the corresponding env variables (or in a .env file)
    # os.environ["RDMS_HOST"] = ...
    # os.environ["ACCESS_TOKEN"] = ...
    # os.environ["DATA_PARTITION_ID"] = "osdu"
    # os.environ["OBJ_URI"] = ...
    # os.environ["PATH_IN_RESOURCES"] = ...

    session_0 = initiate_fetpapi_sessions(
        url=os.getenv("RDMS_HOST"),
        access_token=os.getenv("ACCESS_TOKEN"),
        headers={"data-partition-id": os.getenv("DATA_PARTITION_ID")},
    )
    # Must be done before session starts
    session_0.setDataArrayProtocolHandlers(DataArrayHandlers(session_0))

    # Thread for session 0
    t_0 = Thread(target=start_etp_server, args=(session_0,), daemon=True)
    t_0.start()

    start_time = perf_counter()
    while session_0.isEtpSessionClosed() and perf_counter() - start_time < 5:
        sleep(0.25)
    if session_0.isEtpSessionClosed():
        print("The ETP session could not be established in 5 seconds.")
    else:
        print("Now connected to ETP Server")

    # Print dataspace list to test if the server answer correctly
    for ds in session_0.getDataspaces():
        print(ds.uri)

    # Now test the GetDataArray
    gda = fetpapi.GetDataArrays()
    dai = fetpapi.DataArrayIdentifier()
    dai.uri = os.getenv("OBJ_URI")
    dai.pathInResource = os.getenv("PATH_IN_RESOURCES")
    gda.dataArrays["0"] = dai

    gdar = session_0.sendAndBlock(gda)
    print(gdar) # prints None at the end of the following logs

    session_0.close()

What does happen?

The dataspaces list is correctly printed, but the dataArray is not.

What were you expecting to happen?

I expected to see a message from the handler that should catch the response

Any logs, error output, etc?

Outputs of the script :

Now connected to ETP Server
eml:///dataspace('test/volve')
eml:///dataspace('ilab')
None

Any other comments?

The issue seems not to be on server-side. I am using a personal ETP server. In its logs, I see it answers with a DataArray.
Moreover, with my own etp client, I receive correctly the data array with a similar request.

What versions of FETPAPI are you using?

0.3.1

[philippeVerney]

At a first glance, it looks like a bug. I can reproduce it on my end.
Warning, gdar = session_0.sendAndBlock(gda) is not valid and should raise an ETP exception. Indeed you forgot to add the terminating flag, I presume you want gdar = session_0.sendAndBlock(gda, 0, 0x02) instead.

[philippeVerney]

I think that SWIG directors do not work as I expect for a reason that I don't get for now.