BUG/MINOR: peers: Inconsistency when dumping peer status codes.

A peer connection status must be considered as valid only if there is an applet
which has been instantiated for the connection to the peer. So, ->statuscode
should be considered as the last known peer connection status from the last
connection to this peer if any. To reflect this, "statuscode" field of peer dump
is renamed to "last_statuscode".
This patch also add "active"/"inactive" field after the peer location type
("remote" or "local") if an applet has been instantiated for this peer connection
or not.

Thank you to Emeric for having noticed this issue.

Must be backported in >=1.9 version.

(cherry picked from commit e7e2b21d274ef48da4e45d09786568d2239c9b2a)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
(cherry picked from commit 186bee02a9722e22f0b95f150869ae8e1c3794a9)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>

diff --git a/src/peers.c b/src/peers.c
index b24f0d0..295798e 100644 (file)
--- a/src/peers.c
+++ b/src/peers.c
@@ -3123,9 +3123,10 @@ static int peers_dump_peer(struct buffer *msg, struct stream_interface *si, stru
        struct shared_table *st;
 
        addr_to_str(&peer->addr, pn, sizeof pn);
-       chunk_appendf(msg, "  %p: id=%s(%s) addr=%s:%d status=%s reconnect=%s confirm=%u tx_hbt=%u rx_hbt=%u no_hbt=%u new_conn=%u proto_err=%u\n",
+       chunk_appendf(msg, "  %p: id=%s(%s,%s) addr=%s:%d last_status=%s reconnect=%s confirm=%u tx_hbt=%u rx_hbt=%u no_hbt=%u new_conn=%u proto_err=%u\n",
                      peer, peer->id,
                      peer->local ? "local" : "remote",
+                     peer->appctx ? "active" : "inactive",
                      pn, get_host_port(&peer->addr),
                      statuscode_str(peer->statuscode),
                      peer->reconnect ?