Skip to content

Allow delete() to work on decommissioned systems #41

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

Merged
merged 1 commit into from
Jun 10, 2025
Merged

Conversation

araglu
Copy link
Collaborator

@araglu araglu commented Mar 4, 2025

The @_ensure_connected decorator forces a connection attempt to the HPC before deleting the job, and that fails on any system that no longer exists.

The @_ensure_connected decorator forced a connection attempt to the HPC
before deleting the job, which failed on any system that no longer exists.
@araglu araglu requested a review from sdc50 March 4, 2025 16:27
@sdc50
Copy link
Member

sdc50 commented Mar 26, 2025

By removing @_ensure_connected are we just hoping that the client is already connected by the time this is called? I wonder if we can isolate where it is called.

@araglu
Copy link
Collaborator Author

araglu commented Mar 27, 2025

That decorator is used on other functions like self.stop() and self.client.call() which are called after the logic to avoid working on decommissioned systems. That's why self.clean() doesn't have that decorator and why delete() should not have it.

I just thought about having @_ensure_connected check for decommissioned systems, but I still want delete() to clean up local directories.

@araglu araglu merged commit 81da775 into main Jun 10, 2025
2 checks passed
@araglu araglu deleted the background_tasks branch June 10, 2025 14:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants