v29.4-roots.2 · Commit 15: [PATCH 15/21] fix(qt): clear stale peer details on refresh
doc/roots-features.md
Before: doc/roots-features.md · After: doc/roots-features.md
File metadata
index fedd1e0a9650920b5c959c5a3a33c9b1d31d2e9a..dcf8fe19070216a69ec000a4c057693cd0c52d39 100644
Download original patch · Release notes
Diff rows 1–34 of 34. Line numbers refer to the original before/after files.
+ Added− RemovedUnmarked lines are context.
Scroll the code area horizontally to read long lines. The two line-number columns refer to before and after.
doc/roots-features.md
CHANGED
|
@@ -44,6 +44,19 @@ The retained P2P coverage includes
|
|
|
44
44
|
[`p2p_invalid_messages.py`](/test/functional/p2p_invalid_messages.py).
|
|
45
45
|
This is not a Network Watch or transaction/block activity feed.
|
|
46
46
|
|
|
47
|
+
### Focused peer-health monitoring
|
|
48
|
+
|
|
49
|
+
The existing Debug window's Peers tab provides a bounded, live view of current
|
|
50
|
+
connections. Its sortable table shows connection age, direction, network,
|
|
51
|
+
minimum ping, and sent/received traffic. Selecting one peer shows supported
|
|
52
|
+
connection details including transport (v1 or v2), services, permissions,
|
|
53
|
+
connection type, current ping, and synchronization heights.
|
|
54
|
+
|
|
55
|
+
This uses the node's existing peer-stat refresh and does not retain history or
|
|
56
|
+
inspect transaction or block content. If optional node-state details cannot be
|
|
57
|
+
read during a refresh, the details pane reports them as unavailable instead of
|
|
58
|
+
showing values from an earlier peer.
|
|
59
|
+
|
|
47
60
|
### Wallet and signing hardening
|
|
48
61
|
|
|
49
62
|
The reviewed Roots wallet selection includes database and SQLite error handling,
|
|
@@ -125,11 +138,10 @@ The following areas are approved for evaluation in the follow-on operator
|
|
|
125
138
|
features plan. They are not available merely because they appear in a candidate
|
|
126
139
|
or in this roadmap.
|
|
127
140
|
|
|
128
|
-
1. Focused peer-health monitoring.
|
|
129
|
-
2. Narrow P2P privacy and resource-use hardening.
|
|
130
|
-
3. Wallet database, flush, and backup reliability improvements.
|
|
131
|
-
4. An optional thin per-send RBF control.
|
|
132
|
-
5. Cross-feature regression coverage and catalog reconciliation.
|
|
141
|
+
1. Narrow P2P privacy and resource-use hardening.
|
|
142
|
+
2. Wallet database, flush, and backup reliability improvements.
|
|
143
|
+
3. An optional thin per-send RBF control.
|
|
144
|
+
4. Cross-feature regression coverage and catalog reconciliation.
|
|
133
145
|
|
|
134
146
|
Each item requires its own accepted implementation and tests before it moves to
|
|
135
147
|
the available section. Planned wallet reliability work does not imply a
|