Exception ignored message when creating failed + valid session

[qubixes]

Hi!

During work on one of my PRs we ran into some exception ignored messages such as:

Exception ignored in: <function Connection.__del__ at 0x7af078ff67a0>
Traceback (most recent call last):
  File "/home/qubix/.pyenv/versions/3.11.6/lib/python3.11/site-packages/irods/connection.py", line 132, in __del__
    self.disconnect()
  File "/home/qubix/.pyenv/versions/3.11.6/lib/python3.11/site-packages/irods/connection.py", line 361, in disconnect
    self.send(disconnect_msg)
  File "/home/qubix/.pyenv/versions/3.11.6/lib/python3.11/site-packages/irods/connection.py", line 148, in send
    raise NetworkException("Unable to send message")
irods.exception.NetworkException: Unable to send message

Even though the functionality in iBridges still works fine, this is of course somewhat confusing to the user/us. We first thought it was caused by the new PR, but it seems to originate from the PRC, since installing an old version of PRC removes the message. For reproducing I have found this works relatively consistently:

import sys
from irods.session import iRODSSession

if __name__  == "__main__":
    env_file = sys.argv[1]
    try:
        session = iRODSSession(password="bad_pw", irods_env_file=env_file)
        print(session.server_version)
    except Exception:
        pass
    session = iRODSSession(password="good_pw", irods_env_file=env_file)
    print(session.server_version)

If you can't reproduce it the first time, it might reproduce the second time in my experience.

Looking through the PRC release notes, if found that f2332b3 might be related to this, since I think the issue appears in the cleanup phase.

Let me know if you need more information (I get 4.2.12 for the server version)).

[d-w-moore]

@qubixes What's the scheme used by your client env file ? With native authentication, I wasn't able to reproduce the issue.

[d-w-moore]

Also (again to @qubixes ) - assuming I'm able to reproduce at some point - which older version of PRC corrects the problem?

[d-w-moore]

Will try with SSL enabled. Sometimes that makes a difference.

@qubixes Since the error is incurred while trying to send a disconnect message to the server, on a socket the iRODS server has already given up on, I am pretty sure functionality won't be threatened by the issue underlying this error message.

Perhaps it would be an option to turn this into an INFO level of logged message, instead of an actual exception. Will discuss with the rest of the iRODS Team.

[qubixes]

@d-w-moore I'll just paste my irods_environment.json for completeness:

{
    "irods_host": "geo.data.uu.nl",
    "irods_port": 1247,
    "irods_home": "/nluu11p/home",
    "irods_user_name": "<snip>",
    "irods_default_resource": "irodsResc",
    "irods_zone_name": "nluu11p",
    "irods_authentication_scheme": "pam",
    "irods_encryption_algorithm": "AES-256-CBC",
    "irods_encryption_key_size": 32,
    "irods_encryption_num_hash_rounds": 16,
    "irods_encryption_salt_size": 8,
    "irods_client_server_policy": "CS_NEG_REQUIRE",
    "irods_client_server_negotiation": "request_server_negotiation"
}

[qubixes]

Will try with SSL enabled. Sometimes that makes a difference.

@qubixes Since the error is incurred while trying to send a disconnect message to the server, on a socket the iRODS server has already given up on, I am pretty sure functionality won't be threatened by the issue underlying this error message.

Perhaps it would be an option to turn this into an INFO level of logged message, instead of an actual exception. Will discuss with the rest of the iRODS Team.

Yes, functionally there are no problems, it's just the messaging to the user.

[qubixes]

Also (again to @qubixes ) - assuming I'm able to reproduce at some point - which older version of PRC corrects the problem?

I did a little bit of a manual bisect, and I get the problem with PRC==2.2.0, but not with PRC==2.1.0. Let me know if you need me to bisect on commits.

[trel]

not too many to eyeball there...

v2.1.0...v2.2.0

[d-w-moore]

not too many to eyeball there...

v2.1.0...v2.2.0

No, but I see 2 or 3 that are potentially influencing changes.

[d-w-moore]

Since unhandled exceptions aren't good in finalizers, this loose end should be tied up neatly and logged. But the logging shouldn't be seen at the default level of WARNING, so let's do an INFO level message that simply displays the object representation of the Exception.

[d-w-moore]

It's still elusive to try and reproduce this error, so although I have what I think is a fix, I can't really test it.

[korydraughn]

For now, keep your solution to this in its own branch until we can reproduce it. That keeps other PRs from being blocked by this.

[qubixes]

It's still elusive to try and reproduce this error, so although I have what I think is a fix, I can't really test it.

I could test it if you want!