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

Node.js servers being down fails the CI workflows #20

Closed
sheerlox opened this issue Dec 18, 2024 · 6 comments · Fixed by #23
Closed

Node.js servers being down fails the CI workflows #20

sheerlox opened this issue Dec 18, 2024 · 6 comments · Fixed by #23
Labels
bug Something isn't working released on @alpha

Comments

@sheerlox
Copy link
Owner

When using Nodelix in CI (e.g. through semantic_release), sometimes the Node.js servers are down and the whole CI fails.

We should consider implementing an exponential backoff retry to mitigate that issue and eliminate the need to manually relaunch the workflow (sometimes multiple times).

@sheerlox sheerlox added the bug Something isn't working label Dec 18, 2024
@Lucassifoni
Copy link
Collaborator

Lucassifoni commented Jan 2, 2025

WIP here : alzo-archi@9ab9452

The idea would be to make the backoff optional (the default max_attempts \ 1 param makes it optional) to allow people to control this behavior from the outside (personnally I would launch the install in an Oban job as part of a workflow DAG).

Would that be direction that would suit you ?

I'll have to separate the actual downloading from this, to unit test the backoff separately in my next commits.

@sheerlox
Copy link
Owner Author

sheerlox commented Jan 9, 2025

Looks great, like the direction this is taking!

Regarding the default for max_attempts, I'd personally put a sane number as default (3 or 5), and leave specific use-cases (like running in a DAG) to override it to 1.
I think setting the default to 1 would make sense if the async installation was the main use case, which I don't think it is for now.

What do you think?

@Lucassifoni
Copy link
Collaborator

I think you're right, in that case I'd write a tighter loop that sleeps for max 50ms at a time and checks if a time boundary has been exceeded to decide whether to sleep again or trigger a retry, because I think I remember that sleeping for more than a few tens of milliseconds is suboptimal for the BEAM's preemptive scheduling.
I'll update both code and this ticket after looking that up.

@Lucassifoni
Copy link
Collaborator

Looks I'm wrong on that one, after searching, sleeping is generally discouraged because it's often the wrong tool vs message passing but it's fine here.
I'll switch max attempts to 3 and add tests.

@Lucassifoni
Copy link
Collaborator

Now working on that in #23 .

@sheerlox
Copy link
Owner Author

🎉 This issue has been resolved in version 1.0.0-alpha.15 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working released on @alpha
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants