00:00:05 -xmr-pr- vtnerd opened pull request #9821: Fix HTTP unit tests (broken with new Boost versions)
00:00:05 -xmr-pr- > https://github.com/monero-project/monero/pull/9821
08:49:15 <m-relay> <n​ot_a_money_printer:matrix.org> It FCMP a quantum proof solution?
08:49:19 <m-relay> <n​ot_a_money_printer:matrix.org> Is FCMP a quantum proof solution?
11:34:22 <m-relay> <w​oodser:monero.social> vtnerd `status` shows 1(out)+1(in) connections
12:15:05 -xmr-pr- Gingeropolous opened issue #9822: possible speed up for HDDs, pre-sizing LMDB database to the max instea...
12:15:05 -xmr-pr- > https://github.com/monero-project/monero/issues/9822
12:47:08 <m-relay> <w​oodser:monero.social> I isolated the last problem I'm seeing to 13ff355c, "Set response limits on http server connections": https://github.com/monero-project/monero/commit/13ff355cf6081776fd7379080c17246e35c1236d
12:47:25 <m-relay> <w​oodser:monero.social> vtnerd:
12:50:30 <m-relay> <s​yntheticbird:monero.social> wtf
12:54:29 <m-relay> <o​frnxmr:xmr.mx> This should only effect rpc 👀 uhoh(?)
12:57:00 <sech1> abstract_tcp_server2 is also used in p2p
16:45:20 <m-relay> <v​tnerd:monero.social> woodser: the tx relaying issues were narrowed down to that patch?
16:45:46 <m-relay> <v​tnerd:monero.social> @woodser sorry not on irc
17:58:31 <selsta> vtnerd: please open 9820 against release
18:02:35 <m-relay> <w​oodser:monero.social> vtnerd yes, with that patch, txs aren't being confirmed for some reason
18:15:05 -xmr-pr- vtnerd opened pull request #9823: Add incoming only test [0.18]
18:15:05 -xmr-pr- > https://github.com/monero-project/monero/pull/9823
18:28:31 <selsta> woodser: fail to confirm meaning it prints "Unable to send transaction(s) via Dandelion++ stem" ?
18:31:14 <m-relay> <w​oodser:monero.social> no that only prints if I don't set the `--max-connections-per-ip` flag on 0cd7456
18:32:59 <selsta> ok, is there any error message with 13ff355c?
18:35:42 <m-relay> <w​oodser:monero.social> nope
19:27:40 <m-relay> <v​tnerd:monero.social> woodser:  I don't understand. I thought you narrowed  the issue down to 13ff355c? Or is this situation that with 0cd7456 and 13ff355c txes don't relay, but only 0cd7456 prints an error?
19:33:34 <m-relay> <w​oodser:monero.social> building 0cd7456 will print an error produce test failures unless `--max-connections-per-ip` flag is used
19:34:21 <m-relay> <w​oodser:monero.social> but then there's a different error with 13ff355c, with or without `--max-connections-per-ip`
19:35:32 <m-relay> <w​oodser:monero.social> 0cd7456 will print an error *and fails my tests unless `--max-connections-per-ip` flag is used
19:36:36 <m-relay> <w​oodser:monero.social> both problems appear related to txs not confirming
20:23:15 <m-relay> <v​tnerd:monero.social> What is the error that 13ff355c prints?
20:37:32 <m-relay> <o​frnxmr:xmr.mx> vtnerd  ^
20:40:44 <m-relay> <w​oodser:monero.social> no errors are printed, the tx is not confirmed according to the wallet
20:46:16 <m-relay> <v​tnerd:monero.social> The functional tests for this still work, and appear similar to your haveno test setup, so I don't even have a guess right now
21:14:40 <m-relay> <w​oodser:monero.social> yeah I don't know what it is either, but there's definitely some difference in how the wallets / monerods are behaving with 13ff355c. I just checked again, getting test failures with 13ff355c, which otherwise pass without it
21:19:34 <m-relay> <o​frnxmr:xmr.mx> Do have logs from the tests?
21:19:57 <m-relay> <o​frnxmr:xmr.mx> Is it on a CI that can he looked it?
21:19:59 <m-relay> <o​frnxmr:xmr.mx> Be*
21:59:44 <m-relay> <w​oodser:monero.social> nope, no logs or CI, just a test failure which shows that a wallet does not observe the multisig deposit txs to be unlocked when expected:
21:59:46 <m-relay> <w​oodser:monero.social> ```
21:59:48 <m-relay> <w​oodser:monero.social> Expected: "DEPOSITS_UNLOCKED"
21:59:50 <m-relay> <w​oodser:monero.social> Received: "DEPOSITS_PUBLISHED"
21:59:52 <m-relay> <w​oodser:monero.social> ```
22:00:25 <m-relay> <w​oodser:monero.social> though some of the trades in the test are completing successfully, so it doesn't happen every time