Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stomp Tests Timeout Forever #401

Closed
callumforrester opened this issue Mar 26, 2024 · 12 comments
Closed

Stomp Tests Timeout Forever #401

callumforrester opened this issue Mar 26, 2024 · 12 comments
Assignees
Labels
bug Something isn't working messaging Relates to asynchronous messaging code tests Issues around increasing test coverage/fixing tests

Comments

@callumforrester
Copy link
Collaborator

If I run the stomp tests without a valid message bus running, they should fail within the 10 second timeout (they usually fail earlier when disconnection occurs). They currently hang forever, this behaviour seems to have been present since #345 so probably has something to do with the fact that we are now logging exceptions rather than raising them. This would be unfortunate as it means our solution that made the CLI easier to use makes the tests harder to use.

This ticket is therefore to come up with a solution to #220 that also works for this.

@callumforrester callumforrester added bug Something isn't working tests Issues around increasing test coverage/fixing tests messaging Relates to asynchronous messaging code labels Mar 26, 2024
@stan-dot stan-dot self-assigned this May 1, 2024
@stan-dot
Copy link
Collaborator

stan-dot commented May 1, 2024

this annoyed me just today. one time too many. will fix

@stan-dot
Copy link
Collaborator

stan-dot commented May 2, 2024

got some work for this by mistake into #441

@stan-dot
Copy link
Collaborator

stan-dot commented May 9, 2024

should we have some pytest.mark to NOT run those tests at all in the CI unit test setup? @callumforrester

@callumforrester
Copy link
Collaborator Author

They should always run in CI, and I haven't seen any problems with them in CI, have you?

I see the problem when running locally. We already have a pytest.mark to make them opt-out. We could change it to make them opt-in? Or, like dodal does, include the opt-out in the tox command

@stan-dot
Copy link
Collaborator

nevermind, I missed that mark at first.

@stan-dot
Copy link
Collaborator

todo: should add here in a new PR changes that were explored in #364 PR

@stan-dot stan-dot linked a pull request May 21, 2024 that will close this issue
@stan-dot
Copy link
Collaborator

one possible course of action is to mock - change this in the tests: time.sleep(self._reconnect_policy.initial_delay) so that we don't need to wait

@stan-dot
Copy link
Collaborator

running pytest -m"stomp"

@stan-dot
Copy link
Collaborator

what I see is that the test fails but then the debugger keeps running

@stan-dot
Copy link
Collaborator

going with the debugginer the culprit is here
image

@stan-dot
Copy link
Collaborator

image
this stopped once I check for existing connection before disconnectiong

` def disconnect(self) -> None:
LOGGER.info("Disconnecting...")
if not self.is_connected(): # first new line
return # second new line
# We need to synchronise the disconnect on an event because the stomp Connection
# object doesn't do it for us
disconnected = Event()
self._listener.on_disconnected = disconnected.set
self._conn.disconnect()
disconnected.wait()
self._listener.on_disconnected = None

    `

@stan-dot
Copy link
Collaborator

stan-dot commented Jun 3, 2024

solved with #491

@stan-dot stan-dot closed this as completed Jun 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working messaging Relates to asynchronous messaging code tests Issues around increasing test coverage/fixing tests
Projects
None yet
2 participants