[3.4.5] DSF-Python - timeout failures

[Falcounet]

@oozeBot They are renamed because dsf-python has been refactored mainly to follow DuetAPI

Your imports should be changed as :

from dsf.commands.code import CodeType
from dsf.connections import CommandConnection, InterceptConnection, InterceptionMode
from dsf.object_model import LogLevel, MessageType

[oozeBot]

@Falcounet It's been over 24 hours since the change was made and there have been no timeouts with the service.. however, I did upgrade to the latest version and remove those two lines of code at the same time. I've added the two lines back and will let it run for another 24 hours to see if something else in the latest version fixed the issue and then report back.

[chrishamm]

@oozeBot @Falcounet DSF may send zero-byte payloads to check if the socket is still open. I don't know if the Python client can actually detect that, if it does, those two lines should remain removed.

[oozeBot]

@chrishamm @Falcounet - just caught an error with the latest version.. so it appears Chris is right - DSF is sending zero-byte payloads which triggers this condition.

I'll remove those lines and let it run to see if that, in fact, fixes it.

Jun 08 13:45:59 elevate OCS.py[566]: Traceback (most recent call last):
Jun 08 13:45:59 elevate OCS.py[566]:   File "/opt/dsf/sd/scripts/OCS.py", line 101, in <module>
Jun 08 13:45:59 elevate OCS.py[566]:     cde = intercept_connection.receive_code()
Jun 08 13:45:59 elevate OCS.py[566]:   File "/usr/local/lib/python3.9/dist-packages/dsf/connections/intercept_connectio>
Jun 08 13:45:59 elevate OCS.py[566]:     return self.receive(commands.code.Code)
Jun 08 13:45:59 elevate OCS.py[566]:   File "/usr/local/lib/python3.9/dist-packages/dsf/connections/base_connection.py">
Jun 08 13:45:59 elevate OCS.py[566]:     json_string = self.receive_json()
Jun 08 13:45:59 elevate OCS.py[566]:   File "/usr/local/lib/python3.9/dist-packages/dsf/connections/base_connection.py">
Jun 08 13:45:59 elevate OCS.py[566]:     raise TimeoutError
Jun 08 13:45:59 elevate OCS.py[566]: TimeoutError
Jun 08 13:46:00 elevate systemd[1]: ocs.service: Main process exited, code=exited, status=1/FAILURE

[oozeBot]

@chrishamm @Falcounet - it has been over 3 days without a service crash since those two lines were removed on the latest version.. so it's pretty clear that's the issue.

Please let me know when a new official release is available that removes these two lines so we can update all our machines and test once again. Thanks!

[oozeBot]

@chrishamm @Falcounet - it has been over 4 months without a service crash since those two lines were removed on the latest version.. so it's pretty clear that's the issue.

When will the codebase be updated to correct this issue in a new release? Thanks

[Falcounet]

@oozeBot The codebase was updated some months ago but I forgot to release the new version, sorry.
dsf-python 3.4.6 is released today

[oozeBot]

@Falcounet Thanks! The refactoring broke our code which worked in 3.4.5. I'm still learning and without more examples, I'm not certain what needs to change. Can you guide me through the changes to our declarations to get this working for the new version?

Our Code:

from dsf.commands.code import CodeType
from dsf.connections import CommandConnection, InterceptConnection, InterceptionMode, SubscribeConnection, SubscriptionMode
from dsf.object_model import LogLevel, MessageType

Errors presented in 3.4.6

Nov 01 14:12:45 workbench1 systemd[1]: Started oozeBot Control Server.
Nov 01 14:12:45 workbench1 OCS.py[868]: Traceback (most recent call last):
Nov 01 14:12:45 workbench1 OCS.py[868]:   File "/opt/dsf/sd/scripts/OCS.py", line 17, in <module>
Nov 01 14:12:45 workbench1 OCS.py[868]:     from dsf.commands.code import CodeType
Nov 01 14:12:45 workbench1 OCS.py[868]:   File "/usr/local/lib/python3.7/dist-packages/dsf/__init__.py", line 10, in <module>
Nov 01 14:12:45 workbench1 OCS.py[868]:     from . import commands, connections, http, object_model
Nov 01 14:12:45 workbench1 OCS.py[868]:   File "/usr/local/lib/python3.7/dist-packages/dsf/connections/__init__.py", line 47, in <module>
Nov 01 14:12:45 workbench1 OCS.py[868]:     from .base_command_connection import BaseCommandConnection
Nov 01 14:12:45 workbench1 OCS.py[868]:   File "/usr/local/lib/python3.7/dist-packages/dsf/connections/base_command_connection.py", line 3, in <module>
Nov 01 14:12:45 workbench1 OCS.py[868]:     from .base_connection import BaseConnection
Nov 01 14:12:45 workbench1 OCS.py[868]:   File "/usr/local/lib/python3.7/dist-packages/dsf/connections/base_connection.py", line 6, in <module>
Nov 01 14:12:45 workbench1 OCS.py[868]:     from .init_messages import client_init_messages, server_init_message
Nov 01 14:12:45 workbench1 OCS.py[868]:   File "/usr/local/lib/python3.7/dist-packages/dsf/connections/init_messages/__init__.py", line 1, in <module>
Nov 01 14:12:45 workbench1 OCS.py[868]:     from . import client_init_messages, server_init_message
Nov 01 14:12:45 workbench1 OCS.py[868]:   File "/usr/local/lib/python3.7/dist-packages/dsf/connections/init_messages/client_init_messages.py", line 43, in <module>
Nov 01 14:12:45 workbench1 OCS.py[868]:     auto_flush: bool = True):
Nov 01 14:12:45 workbench1 OCS.py[868]: TypeError: 'type' object is not subscriptable
Nov 01 14:12:45 workbench1 systemd[1]: ocs.service: Main process exited, code=exited, status=1/FAILURE
Nov 01 14:12:45 workbench1 systemd[1]: ocs.service: Failed with result 'exit-code'.

[Falcounet]

@oozeBot I will need more of the source code to understand what is going on, not only the imports.

[oozeBot]

For posterity - this must have been an issue with Python as upgrading to 3.12 resolved the issue I just reported.