Gui

the thing is, this simple goroutine is the one blocked, AFAIU due to the chan pm.newprovs not being read ``` // AddProvider adds a provider func (pm *ProviderManager) AddProvider(ctx context.Context,...

if it reappears, we can reopen this issue

i'm sorry you'll have to rewrite the vochaintest part, but it's for a good cause :)

> i'm sorry you'll have to rewrite the vochaintest part, but it's for a good cause :) in fact, the PR i just merged (causing you conflicts) fixes precisely the...

> I think we should figure out some solution (even if temporary) for this issue. Can we check the error and if matches, retry the transaction @mvdan ? i shamelessly...

got this one today, it looks that this race is still there, just happens very seldom and (i'd guess) when CI server is under load https://github.com/vocdoni/vocdoni-node/actions/runs/3141870432/jobs/5104802900#step:3:10878 ``` 2022-09-28T08:27:50Z FATAL vochaintest/vochaintest.go:923...

nice! being a race condition, i'll spam the CI server with 10 jobs and see if none of them fail

https://github.com/vocdoni/vocdoni-node/actions/runs/3198761522/jobs/5223702308#step:5:425 ``` panic: runtime error: invalid memory address or nil pointer dereference panic: Unclosed iterator at time of Txn.Discard. [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x983feb] goroutine 53946 [running]: github.com/dgraph-io/badger/v3.(*Txn).Discard(0x203006?)...

would a `time.Sleep(blockInterval)` avoid such a refactor? i know, horrible, but in this case maybe it's not worth the effort?

the MTU is already lowered down on clients to 1350, not all clients obey that directive but most do. the ones that don't, would also not obey a "hard" lower...