node0 stderr bitcoin-node: ipc/libmultiprocess/include/mp/proxy-io.h:279: void mp::Waiter::post(Fn &&) [Fn = (lambda at 
                 ./ipc/libmultiprocess/include/mp/type-context.h:67:19)]: Assertion `!m_fn' failed.

07:50:56 < sipa> ryanofsky: any idea about this error in https://github.com/bitcoin/bitcoin/actions/runs/17491932432/job/49683489249?pr=33201 :
07:51:08 < sipa>  node0 stderr bitcoin-node: ipc/libmultiprocess/include/mp/proxy-io.h:279: void mp::Waiter::post(Fn &&) [Fn = (lambda at 
                 ./ipc/libmultiprocess/include/mp/type-context.h:67:19)]: Assertion `!m_fn' failed. 
07:55:12 < kevkevin> looks like the test got hung up on this line in the ipc test: template4 = File "/home/admin/actions-runner/_work/_temp/build/test/functional/interface_ipc.py", line 
                     156, in async_routine: await template2.result.waitNext(ctx, waitoptions)
07:56:46 < sipa> yeah, bitcoin-node crashed during that invocation
08:01:34 < sipa> i can reproduce it locally, though it's pretty rare (once in 60 runs, so far)
08:04:00 < kevkevin> hmm interesting, I'll try to reproduce it locally myself
08:05:03 < ryanofsky> that is interesting, i've never seen that assert hit before. i think it could happen if two ipc clients try to execute a different IPC calls on the same thread at the 
                      same time
08:06:01 < sipa> huh!
08:06:15 < ryanofsky> libmultiprocess assumes a 1:1 threading model where a there is one server thread for every client thread, emulating a traditional c++ call stack
08:06:26 < ryanofsky> allowing recursive mutexes, synchronous callbacks, etc
08:06:37 < sipa> should the python side do anything specific to arrange that?
08:07:01 < sipa> i would assume not, because there is only one thread on the python side that does all IPC calls
08:07:11 < ryanofsky> it should just make two IPC calls at the same time, and they should be calls that do not return instantly like waitNext
08:08:18 < ryanofsky> yeah, it is unexpected that current python test would cause that
08:08:35 < dodo> c
08:10:03 < ryanofsky> maybe there is a race condition where c++ code sends a response but the server thread doesn't return to being idle, and python code sends the next request quickly 
                      enough to hit the assert
08:11:00 < sipa> oh, i may have messed something up
08:11:09 < sipa> waitnext = template2.result.waitNext(ctx, waitoptions)
08:11:14 < sipa> template4 = await template2.result.waitNext(ctx, waitoptions)
08:11:31 < sipa> might create two asynchronous calls simultaneously?
08:12:27 < ryanofsky> it seems like that would just chain the calls so the server runs them back to back, and make the bug more likely to happen
08:13:09 < ryanofsky> but if you added an await on the first line it might prevent this
08:13:40 < sipa> the first one is just unnecessary - i inlined it into the second one, but forgot to remove the original
08:14:06 < sipa> you say "make the bug more likely", so you think that the bug isn't in this code itself, but elsewhere?
08:14:18 < ryanofsky> actually i misread. yeah i assumed you were using waitnext variable second line and the calls would be chained. but actually this does look like simultaneous calls
08:14:44 < sipa> alright, let me run it 1000 times to see if it reappears, but if not, i'm going to assume that was the culprit
08:14:48 < ryanofsky> no i think this code does explain the bug
08:15:15 < sipa> thanks!
08:15:23 < ryanofsky> i just first misread it as chained calls that would be pipelined when actually those are parallel calls
08:15:29 < sipa> right
08:16:14 < ryanofsky> thanks for the test, and finding this. server could definitely do better here, it could just refuse the request instead of asserting
08:18:03 < sipa> or at least a more helpful error message
08:18:23 < sipa> i could imagine third parties trying to use the interface might hit something like this too
08:20:08 < ryanofsky> yeah the error message is the most important thing in practice