Enhancement request: Can't connect to EDDN handling

[athulin]

Describe the enhancement
I occasionally find the status message

Error: Can't connect to EDDN.

This presumably indicates that data from one or more visited systems have not been sent. However, there is no information about what systems are affected (or during what time time issue persisted).

I would like to see some kind of log over systems whose data (wholly or partially) have not been transmitted to EDDN.
This log needs to be copy-paste-able or exportable so that it can be recorded and/or transmitted to someone by mail.

Expected behavior
In addition to the current status '"Error: Can't connect to EDDN." I expect to see

a) a status symbol showing persistently (perhaps a warning symbol) showing if data has or may have been lost. (Once it is turned on, it doesn't turn off in this

b) some way of present more extended information, showing during what time periods (expressed in the same format as the timestamps of the input journal files) this has persisted.

If this is done by the main program or if it is done through a plugin makes no difference for my purpose, only that it is possible to see and access the relevant information.

c) A way to save this information to a file (or to clipboard) for recording.

d) a warning message if the application is closed while there are such outage logs present, giving the user the opportunity to save those logs first, or to close without regard to preserving the logs.

Considered workarounds
None.

I don't know if journal entries can be safely resent to EDDN, If they can, it may be a workaround to use a tool that does that, but so far I have not found anything about that particular scenario.

Additional context
I'm mainly concerned with EDDN data, but there may be reason to include other data source/targets as well. I make no direct request for those, though.

[Athanasius]

As unsent EDDN messages are queued in an sqlite3 database file this could be implemented simply by querying that (which in the meantime you could do yourself using either the sqlite3 command-line tool, or any other you can find).

[athulin]

That suggests that they will be sent later, when the connection has been established -- is that correct? If so, fine: it addresses the basic problem that I was worried about: that some discoveries might be lost.

If so, I suggest some words about that should be added where this particular status message is described. At present it only mentions troubleshooting, suggesting that there's nothing else to do. A note that "If communication with EDDN is interrupted, data that cannot be sent is saved, and will be sent later when communication is reestablished." or whatever better describes how it works would help.

[Athanasius]

Indeed, any EDDN messages that fail to send will be retried later (I forget exactly what I settled on as the triggering mechanism when I changed it from a flat file to the sqlite3 DB, but I seem to recall I decided against trying the entire queue again on each new attempt at sending).