OnionOO problem serving bandwidth documents

https://onionoo.torproject.org/bandwidth?search=binnacle

returns empty result intermittently

added component::metrics/onionoo owner::metrics-team priority::medium resolution::fixed severity::normal status::closed type::defect labels

reproduce with

RVAL=${RANDOM:?} && curl -U

$RVAL:$

RVAL --socks5-hostname 127.0.0.1:9050 'https://onionoo.torproject.org/bandwidth?search=binnacle'

per-IP rate limit on unencrypted directory port requests may be trigger

to be clear, "empty" means

{"version":"7.0",
"build_revision":"7dc8dae",
"relays_published":"2019-10-03 21:00:00",
"relays":[
{"fingerprint":"4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF1F2"}
],
"bridges_published":"2019-10-03 20:47:56",
"bridges":[
]}

fail sticks to particular source IPs

Might be related to an operational issue on one of the two Onionoo hosts. I'm working on that, but it will take a few hours. Will post here when it's done, and then we can see whether issues were related.

Both Onionoo hosts should be back to normal now. Is this still an issue?

Trac:
Status: new to needs_information

Working fine now. A thought is OnionOO could return an error instead of bad data when having problems.

The situation of two concurrently running updaters isn't really something we can test for in order to return an error. What would help is using a lock file, which we did in the past but which had the issue of not running the updater in some edge cases. And what would really help is switching to a database which can handle concurrent access much better than the file system. But that's out of scope for now, so we'll just try hard not to screw up.

Glad to hear it's working again. And thanks for creating this ticket! Closing.

Trac:
Status: needs_information to closed
Resolution: N/A to fixed

closed