-
Notifications
You must be signed in to change notification settings - Fork 113
Only use internal runtime in VssStore
#693
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
base: main
Are you sure you want to change the base?
Only use internal runtime in VssStore
#693
Conversation
|
👋 I see @joostjager was un-assigned. |
db2db6d to
6792792
Compare
|
IIRC the previous hang was reproducible locally. Is that still the case with the hang that this PR fixes? |
We previously attempted to drop the internal runtime from `VssStore`, resulting into blocking behavior. While we recently made changes that improved our situation (having VSS CI pass again pretty reliably), we just ran into yet another case where the VSS CI hung (cf. https://github.com/lightningdevkit/vss-server/actions/runs/19023212819/job/54322173817?pr=59). Here we attempt to restore even more of the original pre- ab3d78d / lightningdevkit#623 behavior to get rid of the reappearing blocking behavior, i.e., only use the internal runtime in `VssStore`.
6792792 to
615c24a
Compare
Unfortunately it's not. And after kicking CI on lightningdevkit/vss-server#59, the flake went away (just as CI in generally now seemed to 'reliably' pass). I am worried though that it might reappear randomly in production. |
|
Is it reproducible by putting a loop around the test in Ci? To ensure that this PR really tackles the problem. |
4f5a9bf to
7456b95
Compare
51c92e2 to
e94fe69
Compare
837f83f to
2911920
Compare
We previously attempted to drop the internal runtime from
VssStore, resulting into blocking behavior. While we recently made changes that improved our situation (having VSS CI pass again pretty reliably), we just ran into yet another case where the VSS CI hung (cf. https://github.com/lightningdevkit/vss-server/actions/runs/19023212819/job/54322173817?pr=59).Here we attempt to restore even more of the original pre- ab3d78d / #623 behavior to get rid of the reappearing blocking behavior, i.e., only use the internal runtime in
VssStore.