payalgo: Remove reporting PAY_TRY_ANOTHER_ROUTE and PAY_UNPARSEABLE_ONION.

These error codes will cause `pay` to retry, so `pay` will never
actually report those error codes.
Those error codes will only get reported at the `sendpay` level.

doc/lightning-pay.7

@@ -2,12 +2,12 @@
 .\"     Title: lightning-pay
 .\"    Author: [see the "AUTHOR" section]
 .\" Generator: DocBook XSL Stylesheets v1.79.1 <http://docbook.sf.net/>
-.\"      Date: 02/19/2018
+.\"      Date: 02/26/2018
 .\"    Manual: \ \&
 .\"    Source: \ \&
 .\"  Language: English
 .\"
-.TH "LIGHTNING\-PAY" "7" "02/19/2018" "\ \&" "\ \&"
+.TH "LIGHTNING\-PAY" "7" "02/26/2018" "\ \&" "\ \&"
 .\" -----------------------------------------------------------------
 .\" * Define some portability stuff
 .\" -----------------------------------------------------------------
@@ -96,21 +96,6 @@ using different amount or destination\&.
 .sp -1
 .IP \(bu 2.3
 .\}
-202\&. Unparseable onion reply\&. The
-\fIdata\fR
-field of the error will have an
-\fIonionreply\fR
-field, a hex string representation of the raw onion reply\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04'\(bu\h'+03'\c
-.\}
-.el \{\
-.sp -1
-.IP \(bu 2.3
-.\}
 203\&. Permanent failure at destination\&. The
 \fIdata\fR
 field of the error will be routing failure object\&.
@@ -124,19 +109,6 @@ field of the error will be routing failure object\&.
 .sp -1
 .IP \(bu 2.3
 .\}
-204\&. Failure along route; retry a different route\&. The
-\fIdata\fR
-field of the error will be routing failure object\&.
-.RE
-.sp
-.RS 4
-.ie n \{\
-\h'-04'\(bu\h'+03'\c
-.\}
-.el \{\
-.sp -1
-.IP \(bu 2.3
-.\}
 205\&. Unable to find a route\&.
 .RE
 .sp
@@ -174,6 +146,8 @@ field of the error indicates
 (the invoice expiration) as UNIX epoch time in seconds\&.
 .RE
 .sp
+Error codes 202 and 204 will only get reported at \fBsendpay\fR; in \fBpay\fR we will keep retrying if we would have gotten those errors\&.
+.sp
 A routing failure object has the fields below:
 .sp
 .RS 4

doc/lightning-pay.7.txt

@@ -54,13 +54,8 @@ The following error codes may occur:
 * 200. A previous *sendpay* or *pay* is in progress.
 * 201. Already paid with this 'hash' using different amount or
   destination.
-* 202. Unparseable onion reply. The 'data' field of the error
-  will have an 'onionreply' field, a hex string representation
-  of the raw onion reply.
 * 203. Permanent failure at destination. The 'data' field of
   the error will be routing failure object.
-* 204. Failure along route; retry a different route. The 'data'
-  field of the error will be routing failure object.
 * 205. Unable to find a route.
 * 206. Route too expensive. The 'data' field of the error will
   indicate the actual 'fee' as well as the 'feepercent'
@@ -72,6 +67,10 @@ The following error codes may occur:
   and 'expiry' (the invoice expiration) as UNIX epoch time in
   seconds.
 
+Error codes 202 and 204 will only get reported at *sendpay*;
+in *pay* we will keep retrying if we would have gotten those
+errors.
+
 A routing failure object has the fields below:
 
 * 'erring_index'. The index of the node along the route that

lightningd/payalgo.c

@@ -77,21 +77,11 @@ static void json_pay_failure(struct command *cmd,
 		break;
 
 	case PAY_UNPARSEABLE_ONION:
-		data = new_json_result(cmd);
+		/* Impossible case */
-		json_object_start(data, NULL);
+		abort();
-		json_add_hex(data, "onionreply",
-			     r->onionreply, tal_len(r->onionreply));
-		json_object_end(data);
-
-		msg = tal_fmt(cmd,
-			      "failed: WIRE_PERMANENT_NODE_FAILURE "
-			      "(%s)",
-			      r->details);
-
 		break;
 
 	case PAY_DESTINATION_PERM_FAIL:
-	case PAY_TRY_OTHER_ROUTE:
 		fail = r->routing_failure;
 		data = new_json_result(cmd);
 
@@ -117,6 +107,11 @@ static void json_pay_failure(struct command *cmd,
 			      r->details);
 
 		break;
+
+	case PAY_TRY_OTHER_ROUTE:
+		/* Impossible case */
+		abort();
+		break;
 	}
 
 	assert(msg);