mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v0.0.3 2021-12-26T01:22:38Z 2021-12-26T01:22:38Z Neel Chauhan neel@neelc.org 2021-12-26T01:22:38Z urn:sha1:383843f0d7d7c0b1f9b75c115fb4bf4a09496dfa 2021-12-20T15:56:24Z Nick Mathewson nickm@torproject.org 2021-12-20T15:56:24Z urn:sha1:6303a71d58849d0bdbd21022eda6fb079ae151e5 These will require thought; should we ignore them, act on them, or continue to treat them as internal errors? 2021-12-09T11:16:23Z Trinity Pointard trinity.pointard@gmail.com 2021-12-09T11:16:23Z urn:sha1:9753a7ee06d1dad9b9dbaa1653593bb545d4cf59 2021-12-06T20:11:03Z Nick Mathewson nickm@torproject.org 2021-12-06T20:01:29Z urn:sha1:31b385c5b20205e879a847a9331c30a37dc2e6f5 We want to only use TODO in the codebase for non-blockers, and open tickets for anything that is a bigger blocker than a TODO. These XXXXs seem like definite non-blockers to me. Part of arti#231. 2021-11-29T16:10:51Z Nick Mathewson nickm@torproject.org 2021-11-29T16:08:34Z urn:sha1:efe165acf3e7467ef31ebe6765c710d4d8c9322b This test seems unreliable on CI: we've got to disable them for now so that we have a working CI system. The CI failure is #238; the ticket to repair them is #244. 2021-11-25T13:20:37Z Daniel Eades danieleades@hotmail.com 2021-11-25T13:14:05Z urn:sha1:db16d13df4779ac61005050dfe5ce05e3d5a1b5d 2021-11-23T22:40:13Z Nick Mathewson nickm@torproject.org 2021-11-23T22:40:13Z urn:sha1:54de7f5cfd82eb04e1e119d1734eee2d6ee1176d 2021-11-18T16:06:53Z eta tor@eta.st 2021-11-18T15:40:18Z urn:sha1:075e663dcd740727ea6832581a38dc6ab0a36d53 The `bad_extend_*` failures were caused by bad test code in `bad_extend_test_impl` that used `futures::join!`; this meant that the reactor could receive the `Extended2` cell before it actually got the `ExtendNtor` request, which caused it to get (quite rightly) confused and close the circuit. Spawning a background thread which has a short delay before sending the `Extended2` cell seems to have alleviated this problem. `new_circ_create_failure` is similar; I think the reactor was getting dropped before it had a chance to flush out its `CreateFast` cell properly, because it had already gotten the result back (since the test code sends it indiscriminately). This was "fixed" in much the same manner as the other test: making it wait a bit before sending the result cell back. There seem to be other tests that use `futures::join!` (like `begindir`?), and use similarly erroneous patterns; I haven't gotten any to fail reliably enough to be able to debug them, though. 2021-11-15T17:57:01Z Nick Mathewson nickm@torproject.org 2021-11-15T17:55:08Z urn:sha1:f92ad644c90480cd6ea738201119ce1e9fd40d8e Closes #222. 2021-11-13T16:22:08Z Nick Mathewson nickm@torproject.org 2021-11-13T16:22:08Z urn:sha1:c6d188869f18c3446f800fe93c37356790187ca7