GitLab

Bandwidth documents are based on bandwidth histories contained in extra-info descriptors, and clients documents are based on directory request statistics contained in bridge extra-info descriptors.

There are situations when a new relay or bridge doesn't report a long-enough bandwidth history for us to write a bandwidth document. And it probably happens even more frequently that a bridge doesn't report directory request statistics, so we don't write a clients document.

The effect is that we may return a details and an uptime document for those relays/bridges, but no bandwidth or clients documents. This may confuse Onionoo clients, which last happend in #9889 (moved).

What we should do is return non-empty bandwidth and clients documents for running relays and bridges. These can contain just the fingerprint and no graph data.

Implementation change:

• When writing a response and can't find a bandwidth or clients file, generate one on the fly that only contains the fingerprint or hashed fingerprint.

Spec changes:

• Make write_history and read_history in bandwidth documents optional. We need to make sure that all known Onionoo clients can handle this change and don't break if these formerly required files go away.
• While doing so, let's make uptime in bridge uptime documents optional. That will also make it consistent with relay uptime documents. This change is not directly related to this bug, but leaving this field required seems inconsistent.