You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
sdc11073 is inconsistent in terms of the term "send", on the one hand on the client side it treats a message as not send if no response has been received from the http server and tries sending it again, on the other hand on the server side it calls the registered callbacks independent of whether a response was send or can be send. sdc11073 should only handle those messages for which it could send a response or should not send again if it could deliver the request bytes, but didn't receive a response
Expected Behavior
consistent client and server implementations
Minimal Reproducible Example
No response
Solution proposal
No response
Python Version
3.11.4
Operating system
"win32" and "linux"
Sdc11073 Version
1.1.28
Link to sdc11073 Logs
No response
Further Information
No response
Participation
I am willing to submit a pull request to fix this bug.
The text was updated successfully, but these errors were encountered:
Just to give an example of why this might be a practical issue:
MdibVersion X arrives via an HTTP request, but no response is given or the response gets dropped, then the MdibVersion X arrives again due to the retry mechanism. From the perspective of the client it was "send" only once, due to no response for the first one, but from the persepctive of the server it was "send" twice actually, which then might result in an error, because it is not allowed for reports other than DescriptionModificationReports.
Is there an existing issue for this?
Current Behavior
sdc11073 is inconsistent in terms of the term "send", on the one hand on the client side it treats a message as not send if no response has been received from the http server and tries sending it again, on the other hand on the server side it calls the registered callbacks independent of whether a response was send or can be send. sdc11073 should only handle those messages for which it could send a response or should not send again if it could deliver the request bytes, but didn't receive a response
Expected Behavior
consistent client and server implementations
Minimal Reproducible Example
No response
Solution proposal
No response
Python Version
3.11.4
Operating system
"win32" and "linux"
Sdc11073 Version
1.1.28
Link to sdc11073 Logs
No response
Further Information
No response
Participation
The text was updated successfully, but these errors were encountered: