The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2024-01-16T13:49:11Zhttps://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/67Avoid NullPointerException when trying to get an exception message2024-01-16T13:49:11ZGeorg KoppenAvoid NullPointerException when trying to get an exception messageWile going over our parser logs I found this interesting bit:
```
2023-12-16 11:50:51,346 WARN o.t.m.d.u.DateTimeHelper:149 VoteParser run().
java.lang.NullPointerException: Cannot invoke "String.length()" because "s" is null
at java.ba...Wile going over our parser logs I found this interesting bit:
```
2023-12-16 11:50:51,346 WARN o.t.m.d.u.DateTimeHelper:149 VoteParser run().
java.lang.NullPointerException: Cannot invoke "String.length()" because "s" is null
at java.base/java.util.Formatter.parse(Formatter.java:2717)
at java.base/java.util.Formatter.format(Formatter.java:2671)
at java.base/java.util.Formatter.format(Formatter.java:2625)
at java.base/java.lang.String.format(String.java:4145)
at org.torproject.metrics.descriptorparser.parsers.VoteParser.addNetworkStatusVote(VoteParser.java:226)
at org.torproject.metrics.descriptorparser.parsers.VoteParser.run(VoteParser.java:85)
at org.torproject.metrics.descriptorparser.Main.run(Main.java:147)
at org.torproject.metrics.descriptorparser.Main.exec(Main.java:36)
at org.torproject.metrics.descriptorparser.Main.main(Main.java:32)
```
I guess what that means is we should be a bit more careful with blocks like
```
} catch (Exception ex) {
logger.warn("Exception. {}".format(ex.getMessage()));
ex.printStackTrace();
}
```
making sure we only try to get a message if it is not `null` (`NullPointerException`s have no messages, for instance, IIRC).https://gitlab.torproject.org/tpo/core/tor/-/issues/40901Document for the Relay Operator community how to debug relays that are slower...2023-12-19T07:53:56ZAlexander Færøyahf@torproject.orgDocument for the Relay Operator community how to debug relays that are slower than what the operator expectsThis idea origins from a conversation betweeh @beth, @gk and I on #tor-dev today.
We often release new features of C Tor to the relay operators that causes discussions/conversations around whether Tor has gotten faster/slower/uses (more...This idea origins from a conversation betweeh @beth, @gk and I on #tor-dev today.
We often release new features of C Tor to the relay operators that causes discussions/conversations around whether Tor has gotten faster/slower/uses (more|less) memory/crashes (more|less) often/etc. many of these items are hard to give a definitive "yes, the cause of this is X" and it's very time consuming for the Network Team to debug each item individually with the operator.
It would be very useful to have a document in place that informs relay operators about the different situations that may impact performance and how they can get some performance measurements they can then compare to and see if our performance have truly regressed. This can also be used to push MetricsPort to more operators.
We can expand upon the document over time as we discover new ways to do this analysis and/or from feedback from the relay operator community.
This is related to:
- https://lists.torproject.org/pipermail/tor-relays/2023-December/021409.html
- https://lists.torproject.org/pipermail/tor-relays/2023-December/021407.html
This may be relevant to Arti Relay too.
CC @mikeperry for awareness.https://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/69`unmeasured`, `vote` (and `consensus_bandwidth_is_unmeasured`) keywords are n...2024-01-16T13:49:09ZGeorg Koppen`unmeasured`, `vote` (and `consensus_bandwidth_is_unmeasured`) keywords are not properly treatedHave a look at the following 2 bw lines and there representation in our DB:
```
./16/2023-12-16-12-38-04-bandwidth-95BC922FA3DB2DDFC7E98ED4A9FFD0138A17BB1DEAD638852C601E55BD5878CF:bw=1 error_circ=5 error_destination=0 error_misc=0 error_...Have a look at the following 2 bw lines and there representation in our DB:
```
./16/2023-12-16-12-38-04-bandwidth-95BC922FA3DB2DDFC7E98ED4A9FFD0138A17BB1DEAD638852C601E55BD5878CF:bw=1 error_circ=5 error_destination=0 error_misc=0 error_second_relay=0 error_stream=0 master_key_ed25519=8VJa1wrFEuyszRnbE9z3D7acLWLvMrRgqodyrZzF1XM nick=TORPi node_id=FFDC0E2EA1D56C555978920C6D26EBA6AFF248FE relay_in_recent_consensus_count=103 relay_recent_measurement_attempt_count=5 relay_recent_measurements_excluded_error_count=5 relay_recent_priority_list_count=5 success=0 time=2023-12-16T00:41:02 unmeasured=1 vote=0 xoff_recv=0 xoff_sent=0
digest | bw | bw_mean | bw_median | consensus_bandwidth | consensus_bandwidth_is_unmeasured | desc_bw_avg | desc_bw_bur | desc_bw_obs_last | desc_bw_obs_mean | error_circ | error_destination | error_misc | error_second_relay | error_stream | master_key_ed25519 | nick | node_id | rtt | relay_in_recent_consensus_count | relay_recent_measurement_attempt_count | relay_recent_measurements_excluded_error_count | relay_recent_measurement_failure_count | relay_recent_measurements_excluded_near_count | relay_recent_measurements_excluded_old_count | relay_recent_measurements_excluded_few_count | relay_recent_priority_list_count | under_min_report | unmeasured | vote | xoff_recv | xoff_sent | success | time | bandwidth_file | r_strm | r_strm_filt
---------------------------------------------+----+---------+-----------+---------------------+-----------------------------------+-------------+-------------+------------------+------------------+------------+-------------------+------------+--------------------+--------------+---------------------------------------------+-------+------------------------------------------+-----+---------------------------------+----------------------------------------+------------------------------------------------+----------------------------------------+-----------------------------------------------+----------------------------------------------+----------------------------------------------+----------------------------------+------------------+------------+------+-----------+-----------+---------+---------------------+---------------------------------------------+--------+-------------
ehnR7l7BXiy24GF9TaeNYXjZBzWPCYff0VmoLRJL22I | 1 | -1 | -1 | -1 | f | -1 | -1 | -1 | -1 | 5 | 0 | 0 | 0 | 0 | 8VJa1wrFEuyszRnbE9z3D7acLWLvMrRgqodyrZzF1XM | TORPi | FFDC0E2EA1D56C555978920C6D26EBA6AFF248FE | 0 | 103 | 5 | 5 | 0 | 0 | 0 | 0 | 5 | f | f | f | 0 | 0 | 0 | 2023-12-16 00:41:02 | lbySL6PbLd/H6Y7Uqf/QE4oXux3q1jiFLGAeVb1YeM8 | 0 | 0
```
and
```
./16/2023-12-16-12-36-10-bandwidth-8AB15BA0804A1CB8B8D251523118156C49107E7DA4B1888965B196365A309864:bw=33000 bw_mean=1157384 bw_median=991611 consensus_bandwidth=34000000 consensus_bandwidth_is_unmeasured=False desc_bw_avg=1073741824 desc_bw_bur=1073741824 desc_bw_obs_last=25973760 desc_bw_obs_mean=30132316 error_circ=0 error_destination=0 error_misc=0 error_second_relay=0 error_stream=0 master_key_ed25519=zak6whupYxRKeYPtIfYJBlQrksWKIVeUYXuyc+WZBM4 nick=Najdorf node_id=$FAF0A8829E39063669FA609B904E0FB8D5E1F23F relay_in_recent_consensus_count=120 relay_recent_measurement_attempt_count=15 relay_recent_priority_list_count=15 success=15 time=2023-12-16T07:41:31
digest | bw | bw_mean | bw_median | consensus_bandwidth | consensus_bandwidth_is_unmeasured | desc_bw_avg | desc_bw_bur | desc_bw_obs_last | desc_bw_obs_mean | error_circ | error_destination | error_misc | error_second_relay | error_stream | master_key_ed25519 | nick | node_id | rtt | relay_in_recent_consensus_count | relay_recent_measurement_attempt_count | relay_recent_measurements_excluded_error_count | relay_recent_measurement_failure_count | relay_recent_measurements_excluded_near_count | relay_recent_measurements_excluded_old_count | relay_recent_measurements_excluded_few_count | relay_recent_priority_list_count | under_min_report | unmeasured | vote | xoff_recv | xoff_sent | success | time | bandwidth_file | r_strm | r_strm_filt
---------------------------------------------+-------+---------+-----------+---------------------+-----------------------------------+-------------+-------------+------------------+------------------+------------+-------------------+------------+--------------------+--------------+---------------------------------------------+---------+-------------------------------------------+-----+---------------------------------+----------------------------------------+------------------------------------------------+----------------------------------------+-----------------------------------------------+----------------------------------------------+----------------------------------------------+----------------------------------+------------------+------------+------+-----------+-----------+---------+---------------------+---------------------------------------------+--------+-------------
NzLgVvhWGgCgxBAaWw/XgeLQxHe3JT1OcZ2ChZWBHSU | 33000 | 1157384 | 991611 | 34000000 | f | 1073741824 | 1073741824 | 25973760 | 30132316 | 0 | 0 | 0 | 0 | 0 | zak6whupYxRKeYPtIfYJBlQrksWKIVeUYXuyc+WZBM4 | Najdorf | $FAF0A8829E39063669FA609B904E0FB8D5E1F23F | 0 | 120 | 15 | 0 | 0 | 0 | 0 | 0 | 15 | f | f | f | 0 | 0 | 15 | 2023-12-16 07:41:31 | irFboIBKHLi40lFSMRgVbEkQfn2ksYiJZbGWNlowmGQ | 0 | 0
```
The first one has `unmeasured=1` and `vote=0` while the latter has both of them missing. Yet in the DB both entries are `f`.
I guess in the first case the `unmeasured` should be `t` and `vote` should be `f` and in the second one it should be `f` and `t`, respectively?
/cc @jugahttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42344Dragging and dropping files on Tor Browser triggers an assertion2024-01-08T11:13:11ZPier Angelo VendrameDragging and dropping files on Tor Browser triggers an assertionDropping a file on Tor Browser to open it triggers an assertion when they are enabled, on the validity of the event timestamp.
I haven't checked if Firefox also has this problem yet, because I don't have a debug build of Firefox.
Verif...Dropping a file on Tor Browser to open it triggers an assertion when they are enabled, on the validity of the event timestamp.
I haven't checked if Firefox also has this problem yet, because I don't have a debug build of Firefox.
Verified on Linux, for now, but might happen also on other platforms.
```c++
TimeDuration operator-(const TimeStamp& aOther) const {
MOZ_ASSERT(!IsNull(), "Cannot compute with a null value");
MOZ_ASSERT(!aOther.IsNull(), "Cannot compute with aOther null value"); // <-- this is the assertion
```
<details><summary>Stack trace</summary>
```
mozilla::TimeStamp::operator-(mozilla::TimeStamp const&) const (/home/piero/Tor/tor-browser/obj-x86_64-pc-linux-gnu/dist/include/mozilla/TimeStamp.h:478)
mozilla::TimeStamp mozilla::SystemTimeConverter<unsigned int, mozilla::TimeStamp>::GetTimeStampFromSystemTime<mozilla::CurrentX11TimeGetter>(unsigned int, mozilla::CurrentX11TimeGetter&) (/home/piero/Tor/tor-browser/widget/SystemTimeConverter.h:110)
nsWindow::GetEventTimeStamp(unsigned int) (/home/piero/Tor/tor-browser/widget/gtk/nsWindow.cpp:4925)
nsWindow::GetWidgetEventTime(unsigned int) (/home/piero/Tor/tor-browser/widget/gtk/nsWindow.cpp:4893)
nsWindow::OnEnterNotifyEvent(_GdkEventCrossing*) (/home/piero/Tor/tor-browser/widget/gtk/nsWindow.cpp:4237)
enter_notify_event_cb(_GtkWidget*, _GdkEventCrossing*) (/home/piero/Tor/tor-browser/widget/gtk/nsWindow.cpp:8023)
___lldb_unnamed_symbol9265 (@___lldb_unnamed_symbol9265:49)
___lldb_unnamed_symbol908 (@___lldb_unnamed_symbol908:104)
___lldb_unnamed_symbol1115 (@___lldb_unnamed_symbol1115:160)
g_signal_emit_valist (@g_signal_emit_valist:21)
g_signal_emit (@g_signal_emit:29)
___lldb_unnamed_symbol17566 (@___lldb_unnamed_symbol17566:109)
gtk_main_do_event (@gtk_main_do_event:474)
___lldb_unnamed_symbol2629 (@___lldb_unnamed_symbol2629:15)
___lldb_unnamed_symbol4021 (@___lldb_unnamed_symbol4021:14)
___lldb_unnamed_symbol2528 (@___lldb_unnamed_symbol2528:128)
___lldb_unnamed_symbol2539 (@___lldb_unnamed_symbol2539:151)
g_main_context_iteration (@g_main_context_iteration:18)
nsAppShell::ProcessNextNativeEvent(bool) (/home/piero/Tor/tor-browser/widget/gtk/nsAppShell.cpp:422)
nsBaseAppShell::DoProcessNextNativeEvent(bool) (/home/piero/Tor/tor-browser/widget/nsBaseAppShell.cpp:131)
nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, bool) (/home/piero/Tor/tor-browser/widget/nsBaseAppShell.cpp:250)
non-virtual thunk to nsBaseAppShell::OnProcessNextEvent(nsIThreadInternal*, bool) (/home/piero/Tor/tor-browser/widget/nsBaseAppShell.cpp:0)
nsThread::ProcessNextEvent(bool, bool*) (/home/piero/Tor/tor-browser/xpcom/threads/nsThread.cpp:1154)
NS_ProcessNextEvent(nsIThread*, bool) (/home/piero/Tor/tor-browser/xpcom/threads/nsThreadUtils.cpp:479)
mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (/home/piero/Tor/tor-browser/ipc/glue/MessagePump.cpp:85)
MessageLoop::RunHandler() (/home/piero/Tor/tor-browser/ipc/chromium/src/base/message_loop.cc:361)
MessageLoop::Run() (/home/piero/Tor/tor-browser/ipc/chromium/src/base/message_loop.cc:343)
nsBaseAppShell::Run() (/home/piero/Tor/tor-browser/widget/nsBaseAppShell.cpp:148)
nsAppStartup::Run() (/home/piero/Tor/tor-browser/toolkit/components/startup/nsAppStartup.cpp:295)
XREMain::XRE_mainRun() (/home/piero/Tor/tor-browser/toolkit/xre/nsAppRunner.cpp:5826)
XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) (/home/piero/Tor/tor-browser/toolkit/xre/nsAppRunner.cpp:6026)
XRE_main(int, char**, mozilla::BootstrapConfig const&) (/home/piero/Tor/tor-browser/toolkit/xre/nsAppRunner.cpp:6082)
do_main(int, char**, char**) (/home/piero/Tor/tor-browser/browser/app/nsBrowserApp.cpp:227)
main (/home/piero/Tor/tor-browser/browser/app/nsBrowserApp.cpp:445)
__libc_start_call_main (@__libc_start_call_main:26)
__libc_start_main_impl (@__libc_start_main@@GLIBC_2.34:43)
_start (@_start:14)
```
</details>
Other kind of drag and drops (e.g., tabs/links from Firefox) work, but I haven't done an extended test.ma1ma1https://gitlab.torproject.org/tpo/tpa/team/-/issues/41454Migrate metrics-store-01 to object storage2024-01-04T19:34:23ZHiroMigrate metrics-store-01 to object storageWe have agreed we can migrate metrics-store-01 to object storage.We have agreed we can migrate metrics-store-01 to object storage.HiroHirohttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42350newwin: consider exempting some `moz-extension://` scheme windows2024-03-12T09:04:47ZThorinnewwin: consider exempting some `moz-extension://` scheme windowsI'm not sure of the ramifications here, because once a window is created it can be used - but not if the urlbar etc is missing, so we can probably detect that
https://github.com/mullvad/mullvad-browser/issues/202
tl;dr: bitwarden chang...I'm not sure of the ramifications here, because once a window is created it can be used - but not if the urlbar etc is missing, so we can probably detect that
https://github.com/mullvad/mullvad-browser/issues/202
tl;dr: bitwarden changed from using a new window (in reality in a new tab) to a using a small resized window anchored to the top right - for UX reasons - the problem is, RFP's new win will open it at 1400 x 900 max.
here's how it should look (I'm just using a blank page, it makes more sense on a login)
![bitwarden](/uploads/b71c4f91ac347512424899f1dbf2a882/bitwarden.png)
here's what actually happens
- if you have the width, it actually positions top/left correctly, but the dimensions is the issue. I have just moved the second window for this image
![bitwarden-RFP](/uploads/aca05e5e8988dcc829d9c01dc76581b4/bitwarden-RFP.png)
Note: the scheme is `moz-extension://` and the window has no tabstrip, urlbar, toolbar - so this means it's useless to repurpose for loading websites, so we should be good to exempt these cases from newwin dimensions
@ma1 cc @pierovma1ma1https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel/-/issues/311 webtunnel bridge instead of two!2024-02-27T19:09:02Zcypherpunks1 webtunnel bridge instead of two!You should give at least two bridges for conflux to work.You should give at least two bridges for conflux to work.meskiomeskio@torproject.orgmeskiomeskio@torproject.orghttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/42362"New window" missing from File menu on macOS2024-01-10T07:30:30Zdonuts"New window" missing from File menu on macOSAt some point we seem to have lost the option to open a new window via the File menu on macOS.
[macos-file-menu](/uploads/aa06119db881fb40797f7500c3057e1c/macos-file-menu.png)At some point we seem to have lost the option to open a new window via the File menu on macOS.
[macos-file-menu](/uploads/aa06119db881fb40797f7500c3057e1c/macos-file-menu.png)https://gitlab.torproject.org/tpo/core/arti/-/issues/1196Remove all vestiges of HsClientIntroAuthKeypair and friends2024-01-10T20:11:25ZNick MathewsonRemove all vestiges of HsClientIntroAuthKeypair and friendsThese are deprecated, and we can probably afford to remove them soon.These are deprecated, and we can probably afford to remove them soon.https://gitlab.torproject.org/tpo/core/arti/-/issues/1216Improve descriptor publisher documentation2024-02-01T13:08:27Zgabi-250Improve descriptor publisher documentationArti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/1217Consider adding a keystore watcher2024-01-11T18:45:15Zgabi-250Consider adding a keystore watcherSometimes we want to react to keystore changes. For example, if the identity of the service is rotated through some external means (e.g. via the `arti hss` command), the descriptor publisher needs to create and publish a new descriptor (...Sometimes we want to react to keystore changes. For example, if the identity of the service is rotated through some external means (e.g. via the `arti hss` command), the descriptor publisher needs to create and publish a new descriptor (using the newly generated keys).
* do we want the ability to "watch" keystores? What would the implementation for this look like? Should the `Keystore` trait have a function that returns the receiving end of an e.g. `postage::watch` channel? Will the channel return a `()` indicating something changed (without specifying what), or should it return the list of affected `KeyPath`s (or the corresponding `KeyPathPattern`s)?
* implementing this for FS-based keystores is fairly easy, but what about the HSM-based ones?Arti: Onion service supporthttps://gitlab.torproject.org/tpo/core/arti/-/issues/1218Consider moving logging out of publisher reactor2024-01-30T17:34:35Zgabi-250Consider moving logging out of publisher reactor```rust
netidr_event = netdir_events.next().fuse() => {
// The consensus changed. Grab a new NetDir.
let netdir = match self.dir_provider.netdir(Timeliness::Timely) {
Ok(y) ...```rust
netidr_event = netdir_events.next().fuse() => {
// The consensus changed. Grab a new NetDir.
let netdir = match self.dir_provider.netdir(Timeliness::Timely) {
Ok(y) => y,
Err(e) => {
error_report!(e, "HS service {}: netdir unavailable. Retrying...", self.imm.nickname);
// Hopefully a netdir will appear in the future.
// in the meantime, suspend operations.
//
// TODO HSS there is a bug here: we stop reading on our inputs
// including eg publish_status_rx, but it is our job to log some of
// these things. While we are waiting for a netdir, all those messages
// are "stuck"; they'll appear later, with misleading timestamps.
//
// Probably this should be fixed by moving the logging
// out of the reactor, where it won't be blocked.
wait_for_netdir(self.dir_provider.as_ref(), Timeliness::Timely)
.await?
}
};
self.handle_consensus_change(netdir).await?;
}
```Arti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/1220Implement the `arti hss` subcommand2024-02-21T17:04:15Zgabi-250Implement the `arti hss` subcommandWe need to implement roughly what is described in !1730We need to implement roughly what is described in !1730Arti: Onion service supportgabi-250gabi-250https://gitlab.torproject.org/tpo/core/arti/-/issues/1222Add central documentation for our filesystem layout2024-02-01T15:43:34ZNick MathewsonAdd central documentation for our filesystem layoutSomewhere in doc/dev, we should document all the files that we create or look at.
This will include:
* `tor-keymgr` stuff, possibly by reference
* All state files
* All onion-service-related files
* All cache files
* All locks...Somewhere in doc/dev, we should document all the files that we create or look at.
This will include:
* `tor-keymgr` stuff, possibly by reference
* All state files
* All onion-service-related files
* All cache files
* All locks
* All configuration files
This should replace `crates/tor-hsservice/src/state_dir.md` (cc @diziet)https://gitlab.torproject.org/tpo/core/tor/-/issues/40907Starting tor with --DormantOnFirstStartup doesn't set GETINFO dormant to 12024-01-24T19:08:12ZCrazyChaozStarting tor with --DormantOnFirstStartup doesn't set GETINFO dormant to 1### Summary
Starting tor with --DormantOnFirstStartup 1 on a new DataDirectory doesn't set GETINFO dormant to 1
### Steps to reproduce:
1. start tor with ```tor --DormantOnFirstStartup 1 --DataDirectory some-empty-dir```
2. do a ```GE...### Summary
Starting tor with --DormantOnFirstStartup 1 on a new DataDirectory doesn't set GETINFO dormant to 1
### Steps to reproduce:
1. start tor with ```tor --DormantOnFirstStartup 1 --DataDirectory some-empty-dir```
2. do a ```GETINFO dormant```
### What is the current bug behavior?
GETINFO dormant returns 0, as if it weren't in dormant mode
### What is the expected behavior?
GETINFO dormant returns 1, as it is in dormant mode
### Environment
- Which version of Tor are you using? Run `tor --version` to get the version if you are unsure.
- 0.4.6.10 and 0.4.5.10
- Which operating system are you using? For example: Debian GNU/Linux 10.1, Windows 10, Ubuntu Xenial, FreeBSD 12.2, etc.
- Pop!_OS 22.04 and Ubuntu 18.04.6
- Which installation method did you use? Distribution package (apt, pkg, homebrew), from source tarball, from Git, etc.
- apt and ?Tor: 0.4.9.x-freezehttps://gitlab.torproject.org/tpo/web/donate-neo/-/issues/15Promote common styles, assets and components to lego successor2024-01-16T22:12:42ZdonutsPromote common styles, assets and components to lego successorDescription TBD.Description TBD.https://gitlab.torproject.org/tpo/core/arti/-/issues/1250Add CLI tests for `arti hss`2024-01-17T13:57:38Zgabi-250Add CLI tests for `arti hss`Arti: Onion service supporthttps://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/75Include fallback dir update script logic into descriptorParser2024-01-18T08:19:59ZHiroInclude fallback dir update script logic into descriptorParserWe have an ant task for the website that runs a python script and update the fallback dirs list on the website. We should have that logic in descriptorParser and add the flag to the appropriate relays.We have an ant task for the website that runs a python script and update the fallback dirs list on the website. We should have that logic in descriptorParser and add the flag to the appropriate relays.https://gitlab.torproject.org/tpo/core/arti/-/issues/1252OnionServicePrefs2024-01-23T16:54:08Zgabi-250OnionServicePrefsThe following discussion from !1887 should be addressed:
- [ ] @nickm started a [discussion](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1887#note_2984621): (+5 comments)
> Here's a thought. What would you think ...The following discussion from !1887 should be addressed:
- [ ] @nickm started a [discussion](https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1887#note_2984621): (+5 comments)
> Here's a thought. What would you think about adding a new `prefs` argument to OnionService here? It could, for example, include information about whether we should construct the keys if they are not already found.Arti: Onion service supporthttps://gitlab.torproject.org/tpo/network-health/metrics/descriptorParser/-/issues/76extra_info_descriptor table default or wrong values2024-01-24T10:15:16Zjugaextra_info_descriptor table default or wrong valuesWorking on tpo/network-health/team#313, i thought to include whether a relay is overloaded in the grafana panels, so i tried this query:
```
select overload_ratelimits_version, overload_ratelimits_timestamp, overload_ratelimits_ratelimit...Working on tpo/network-health/team#313, i thought to include whether a relay is overloaded in the grafana panels, so i tried this query:
```
select overload_ratelimits_version, overload_ratelimits_timestamp, overload_ratelimits_ratelimit, overload_ratelimits_burstlimit , overload_ratelimits_read_count, overload_ratelimits_write_count, overload_fd_exhausted_version, overload_fd_exhausted_timestamp
from extra_info_descriptor
where fingerprint='0E13738FADDE15FC896E7CDB998C694F89F4E4B2';
```
which returns many rows as:
```
overload_ratelimits_version | overload_ratelimits_timestamp | overload_ratelimits_ratelimit | overload_ratelimits_burstlimit | overload_ratelimits_read_count | overload_ratelimits_write_count | overload_fd_exhausted_version | overload_fd_exhausted_timestamp
-----------------------------+-------------------------------+-------------------------------+--------------------------------+--------------------------------+---------------------------------+-------------------------------+---------------------------------
0 | 1969-12-31 23:59:59.999 | -1 | -1 | -1 | -1 | 0 | 1969-12-31 23:59:59.999
```
Maybe we could allow all these values to be NULL if the relay isn't overloaded?
I then tried to filter overload_ratelimits_read_count and overload_ratelimits_write_count without `-1` values and had to treat them as strings for that:
```
select count (*)
from extra_info_descriptor
where overload_ratelimits_write_count!='-1' and overload_ratelimits_read_count!='-1';
count
--------
169536
```
So maybe there's a bug here?
Maybe this was introduced by #47 (which i reviewed, ahem ;))
On a different issue, i think it'd be very helpful to add a VictoriaMetric metric to know whether a relay is overloaded.