📅 Original date posted:2015-09-30
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> On Wed, Sep 30, 2015 at 11:11:09AM +0930, Rusty Russell wrote:
>> > (I'm not following why the state coverage testing doesn't do something
>> > more like: [...]
>> Sure, but that's not even close to exhaustive testing (drawing diagrams
>> was just a side-effect for me).
>
> Absolutely. But... I'm not seeing what the code actually /does/ with the
> exhaustive testing? There's a lot of asserts; but I'm not sure that's
> actually testing things "make sense" or just "don't crash". Maybe having
> some optional output of traces for successful test cases would make it
> more obvious?
More comments and more testing would be nice, but at some point I have
to stop writing tests :)
Tests are (with varying degrees of thoroughness):
1) State machine never gets into an invalid state.
2) State machine never sends a packet other side doesn't expect.
3) State machine terminates if not on main loop.
4) State machine does not deadlock (both sides waiting, none sending).
5) State machine cleans up.
> eg, (and I haven't tried pulling the code apart to really understand
> it or anything) I can't tell if you're testing agreeing on two HTLCs then
> having the first one time out, versus the second one time out first.
>
> Hmm:
>
> report_trail(&t, "CLOSED with htlc in progress?");
>
> I figured that was expected and normal protocol behaviour? Not ideal,
> but if you're still communicating at all, if someone decides the channel
> has to be closed, it's still always better to do a mutual close to
> avoid the CSV delays and any unnecessarily elevated fees, even with
> outstanding HTLCs.
STATE_CLOSED here means "completely finished".
But also, we don't support mutual close with outstanding HTLCs. We
could, but the protocol is complex enough already.
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:44:41
in reply to nevent1q…jwce
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:44:41Event JSON
{
"id": "7c9634b943bcc6c94fab845e43b127ad900f3c0ed781d61522312d68fbe6892e",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314681,
"kind": 1,
"tags": [
[
"e",
"9128208f979ba16b9ae0be51d665e61e4d39f4748bd35992d09bb44edfaa05bc",
"",
"root"
],
[
"e",
"5acd549517658dc8d6b7899cf107b09e78299982b5514e9ccaf03cf998d11a8e",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "📅 Original date posted:2015-09-30\n📝 Original message:\nAnthony Towns \u003caj at erisian.com.au\u003e writes:\n\u003e On Wed, Sep 30, 2015 at 11:11:09AM +0930, Rusty Russell wrote:\n\u003e\u003e \u003e (I'm not following why the state coverage testing doesn't do something\n\u003e\u003e \u003e more like: [...]\n\u003e\u003e Sure, but that's not even close to exhaustive testing (drawing diagrams\n\u003e\u003e was just a side-effect for me).\n\u003e\n\u003e Absolutely. But... I'm not seeing what the code actually /does/ with the\n\u003e exhaustive testing? There's a lot of asserts; but I'm not sure that's\n\u003e actually testing things \"make sense\" or just \"don't crash\". Maybe having\n\u003e some optional output of traces for successful test cases would make it\n\u003e more obvious?\n\nMore comments and more testing would be nice, but at some point I have\nto stop writing tests :)\n\nTests are (with varying degrees of thoroughness):\n\n1) State machine never gets into an invalid state.\n2) State machine never sends a packet other side doesn't expect.\n3) State machine terminates if not on main loop.\n4) State machine does not deadlock (both sides waiting, none sending).\n5) State machine cleans up.\n\n\u003e eg, (and I haven't tried pulling the code apart to really understand\n\u003e it or anything) I can't tell if you're testing agreeing on two HTLCs then\n\u003e having the first one time out, versus the second one time out first.\n\u003e\n\u003e Hmm:\n\u003e\n\u003e report_trail(\u0026t, \"CLOSED with htlc in progress?\");\n\u003e\n\u003e I figured that was expected and normal protocol behaviour? Not ideal,\n\u003e but if you're still communicating at all, if someone decides the channel\n\u003e has to be closed, it's still always better to do a mutual close to\n\u003e avoid the CSV delays and any unnecessarily elevated fees, even with\n\u003e outstanding HTLCs.\n\nSTATE_CLOSED here means \"completely finished\".\n\nBut also, we don't support mutual close with outstanding HTLCs. We\ncould, but the protocol is complex enough already.\n\nCheers,\nRusty.",
"sig": "82cf2795370a73a26ca6f9df9835feb04214b25fc3123b26d410914fcc6295cf4e8e569fef4cae964e7a85ba901fa285035884797d4f4a13a51c02e371825755"
}