Getting an exception when trying to close AsyncModbusSerialClient

[anantSwajal]

I am using a USB dongle (RS 485) to communicate with a raspberry pi through serial communication. Whenever I try to close the client I get the following error -

Exception in callback SerialTransport._call_connection_lost(None)
handle: <Handle SerialTransport._call_connection_lost(None)>
Traceback (most recent call last):
  File "/usr/lib/python3.9/asyncio/events.py", line 80, in _run
    self._context.run(self._callback, *self._args)
  File "/home/pi/.local/lib/python3.9/site-packages/pymodbus/client/serial_asyncio/__init__.py", line 426, in _call_connection_lost
    self._serial.flush()
AttributeError: 'NoneType' object has no attribute 'flush'

Here is a stripped down version of my code-

from pymodbus.client import AsyncModbusSerialClient
import time
import asyncio

client=AsyncModbusSerialClient(port='/dev/ttyUSB0',baudrate=4800,timeout=10,parity='N')
SLAVE = 0x01

async def get_data_async(db):
    await client.connect()
    panel_read= _check_call(await client.read_holding_registers(0,40, slave=SLAVE))
    data_obj = {read register data}
    await client.close() 
    db.set_data(data_obj)

def get_and_store_data(db):
     asyncio.run(get_data_async(db))

def _check_call(rr):
    """Check modbus call worked generically."""
    assert not rr.isError()  # test that call was OK
    assert not isinstance(rr, ExceptionResponse)  # Device rejected request
    return rr

I am not sure if I am doing something wrong but it seems like the bug is in the library. Can anyone shed some light in the issue? Thankfully the connection does close and the rest of the code works as expected, it just adds a lot of trash to our logs. I am on pymodbus version 3.2.2 and Python 3.9.2.

[janiversen]

looks like a bug, I will investigate a bit.

[janiversen]

the trace back is not complete, I cannot see which of the functions you call provoke the exception.

[janiversen]

you have a raising effect, which we have not seen before, and which I cannot explain. However I just merged a commit, that ensures you do not get an exception.

It is available on dev, and will be part of version 3.3

[anantSwajal]

Thank you for your prompt response. Just took a look at the commit and that should fix our troubles. The traceback I posted was all the information it gave me, if there is a way to get a more verbose traceback I would gladly share it with you.

I am not sure what you mean by raising effect to be honest. Since all the functionality is working, I think your fix is good enough for the issue and this probably doesn't need to be investigated further. Thank you once again.