Send success/fail with signing - dev branch

[stranger]

I'm trying to work out if a change between ver 1.5 and 2.0 is deliberate.
The case is a node sending a message that requires signing, but signing failed (e.g. nonce timeout).
In previous versions (1.5) , this would result in the send function returning false.
In the current dev branch, this results in signerSignMsg returning false, but the message itself can be sent and return "st=ok", e.g.:

send: 4-4-97-0 s=4,c=3,t=16,pt=0,l=0,sg=0,st=ok:
Nonce requested from 0. Waiting...
Message to send could not be signed!
sign fail
send: 4-4-97-0 s=4,c=2,t=36,pt=0,l=0,sg=0,st=ok:

So the send function returns true, even though the gateway will discard the message (presumably).

I seem to have lots of radio issues, so I want my nodes to repeat status updates until the send is confirmed.

I guess my question is this: should the send function (transportSendWrite) be changed so that if signing fails, the send fails, or should I go about this differently (e.g. using ack's, or testing with mGetSigned)?

p.s. I'm fairly new to the forum, and github, so I'm not sure where the best place to post this is - let me know if it's not appropriate here.

[Anticimex]

@stranger hm, good question. I do not recall changing this behavior, but there have been some updates in other parts of the library as well recently. @hek @tekka @tbowmo what do you think? A quick fix to this in the transport?

[stranger]

I just found the discussion on reliable delivery , which clears up some things.
I believe the v2.0 send function returns "hop-to-hop" acknowledgment - i.e. if the message got delivered to the next node.
Therefore I should use software ack's from the gateway to confirm message delivery, though it appears to be an ongoing discussion.
There's still the question of how signing fits in, but it's not so relevant to my case anymore - regardless of whether it fails because of signing or something else, the result will be no ack from the gateway.

[Anticimex]

@stranger ok, thanks for the heads up though. It's sometimes tough to keep track on all activities and how they relate to each other.

[tekka]

@stranger @Anticimex Fixed in PR#503