-
Notifications
You must be signed in to change notification settings - Fork 2.7k
try-runtime-cli: improve ci stability #14030
try-runtime-cli: improve ci stability #14030
Conversation
…y-runtime-ci-stability
…y-runtime-ci-stability-improvements
niklasad1
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me
It would be safer to create a new HttpClient in each thread spawned in the "remote externalities" than to limit the number of threads, fine for now
Yup I was considering this but it seems like it would require a larger refactor. We'll be doing a large refactor later anyway for lazy-download, and CI seems happy with this configuration, so decided not to do it here. |
ggwpez
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
* hardcode 1 thread * ci stability * fix comment * improve comment * kick ci * kick ci * update expect message * improve comment * kick ci * kick ci * configure threads with env var * fix threads env var * fix threads env var
* hardcode 1 thread * ci stability * fix comment * improve comment * kick ci * kick ci * update expect message * improve comment * kick ci * kick ci * configure threads with env var * fix threads env var * fix threads env var
HttpClientBuilderconfig to fix some stability issues with the CI and increase the max possible batch sizeHttpClient("dispatch dropped without returning error" when using Client from tests hyperium/hyper#2112)the on_chain version is equal or more than the current one. I guess we need to update its Migrations struct? If so, I'm happy to handle that in a seperate PR.Closes #14013 and #14006