We were trying to connect, but they disconnected. */
| 259 | |
| 260 | /* We were trying to connect, but they disconnected. */ |
| 261 | static void connect_failed(struct lightningd *ld, |
| 262 | const struct node_id *id, |
| 263 | const struct wireaddr_internal *addrhint, |
| 264 | const char *connect_reason, |
| 265 | u64 connect_nsec, |
| 266 | enum jsonrpc_errcode errcode, |
| 267 | const char *errmsg, |
| 268 | bool connect_attempted) |
| 269 | { |
| 270 | struct connect *c; |
| 271 | |
| 272 | /* Don't record twice. */ |
| 273 | if (errcode != CONNECT_DISCONNECTED_DURING) |
| 274 | wallet_save_network_event(ld, id, |
| 275 | NETWORK_EVENT_CONNECTFAIL, |
| 276 | errmsg, |
| 277 | connect_nsec, |
| 278 | connect_attempted); |
| 279 | |
| 280 | /* There's a race between autoreconnect and connect commands. This |
| 281 | * matters because the autoreconnect might have failed, but that was before |
| 282 | * the connect_to_peer command gave connectd a new address. This we wait for |
| 283 | * one we explicitly asked for before failing. |
| 284 | * |
| 285 | * A similar pattern could occur with multiple connect commands, however connectd |
| 286 | * does simply combine those, so we don't get a response per request, and it's a |
| 287 | * very rare corner case (which, unlike the above, doesn't happen in CI!). |
| 288 | */ |
| 289 | if (strstarts(connect_reason, "connect command") |
| 290 | || errcode == CONNECT_DISCONNECTED_DURING) { |
| 291 | /* We can have multiple connect commands: fail them all */ |
| 292 | while ((c = find_connect(ld, id)) != NULL) { |
| 293 | /* They delete themselves from list */ |
| 294 | was_pending(command_fail(c->cmd, errcode, "%s", errmsg)); |
| 295 | } |
| 296 | } |
| 297 | } |
| 298 | |
| 299 | void connect_failed_disconnect(struct lightningd *ld, |
| 300 | const struct node_id *id, |
no test coverage detected