anti-censorship-team

anti-censorship-team@lists.torproject.org

June 2026

1 participants
1 discussions

The format of snowflake-stats descriptors and collector-rs
by David Fifield 08 Jul '26

08 Jul '26

For the past 3 months, collector-rs has been making snowflake-stats tarballs in an incorrect format. The recently committed fix for this problem implies that the incorrect format was the result of the Snowflake broker changing the format of its metrics. But this is not the case: Snowflake broker metrics have always (since 2019) contained multiple days of metrics. This was by design, and Java Collector was always able to parse that format. Since the recent fix, collector-rs treats snowflake-stats as a special case ("skip_seed_for_archive"), but Java Collector didn't treat snowflake-stats as exceptional—it parsed snowflake-stats in the same way as other types that have multiple days of data in one file, like bridgedb-metrics and bridgestrap-stats, using a method called parseOneOrMoreDescriptors. In summary, the problem was with collector-rs not parsing the metrics files in the same way as Java Collector did, not because of any change in the output of the Snowflake broker. snowflake-stats is not really a special case, but the collector-rs code now treats it as a special case, which makes me wonder if it could be handled in a more uniform way. This is the issue for collector-rs serving an incorrect format for snowflake-stats tarballs: "Snowflake stats format is broken for April" https://gitlab.torproject.org/tpo/network-health/metrics/collector-rs/-/wor… This is the merge request that closes #48 along with many other things: "Rework archive/publish/sync pipeline; add bridge import; vote & dirauth fixes" https://gitlab.torproject.org/tpo/network-health/metrics/collector-rs/-/mer… I understand that the fix has two parts: 1. Changing the collector-rs to ignore all but the last "snowflake-stats-end": https://gitlab.torproject.org/tpo/network-health/metrics/collector-rs/-/mer… 2. Running a one-time fix_snowflake script that rewrites past downloaded files so that they contain only the last "snowflake-stats-end": https://gitlab.torproject.org/juga/collector-fixes/-/commit/7b0aa3170313cb4… I'll quote from fix_snowflake.rs, because I think it reveals the misunderstanding on the collector-rs side: //! `fix-snowflake` - trim bloated snowflake-stats files down to a single //! reporting period, both in `out/recent/snowflakes/` and in the monthly //! `out/archive/snowflakes/snowflake-stats-*.tar.xz` tarballs. //! //! ## Background //! //! The snowflake broker's `/metrics` endpoint is meant to return a single //! `snowflake-stats-end <date> <time> (86400 s)` reporting block per fetch. //! Starting around collector-rs's deployment in 2026, the broker began //! returning the **entire cumulative history** since 2024-09-19 on every //! fetch instead: every previous day's block concatenated, with the new //! day's block appended at the end. Every file collector-rs wrote during //! that window inherited that bloat verbatim - both the daily files in //! `out/recent/snowflakes/` and the entries written into the monthly //! archive tarballs. The format emitted by the broker /metrics endpoint is not "bloat" and it is not "incorrect". Nor did the format change at any point. Here's a Wayback capture that shows it worked like that in 2020: https://web.archive.org/web/20200619131042/https://snowflake-broker.torproj… The format was intentionally designed this way. Here is part of a conversation with Karsten when the metrics feature was originally designed: https://gitlab.torproject.org/tpo/network-health/metrics/collector/-/work_i… To answer your earlier question above: having just the last 24 hours of data might be problematic if the metrics host goes down for, say, a weekend. Ideally, there would be at least a week of statistics available. Or maybe just accumulate new statistics forever, given the tiny amount of statistics per day. This is the way it is intended to work and the way it worked before. collector-rs should not treat the format as anomalous or unexpected. The old metrics/library had a test case with 2 descriptors in it, since 2019: https://gitlab.torproject.org/tpo/network-health/metrics/library/-/blob/2b6… This is how the old metrics/library handled snowflake-stats descriptors: https://gitlab.torproject.org/tpo/network-health/metrics/library/-/blob/2b6… } else if (firstLines.startsWith("@type snowflake-stats 1.") || firstLines.startsWith(Key.SNOWFLAKE_STATS_END.keyword + SP) || firstLines.contains(NL + Key.SNOWFLAKE_STATS_END.keyword + SP)) { return this.parseOneOrMoreDescriptors(rawDescriptorBytes, sourceFile, Key.SNOWFLAKE_STATS_END, SnowflakeStatsImpl.class); } It called parseOneOrMoreDescriptors with "snowflake-stats-end" as a delimiter. Then it iterated over parsed descriptor and handled each one individually: https://gitlab.torproject.org/tpo/network-health/metrics/collector/-/blob/0… DescriptorParser descriptorParser = DescriptorSourceFactory.createDescriptorParser(); SortedSet<LocalDateTime> snowflakeStatsEnds = new TreeSet<>(); this.outputPathName = config.getPath(Key.OutputPath).toString(); for (Descriptor descriptor : descriptorParser.parseDescriptors( downloadedBytes, null, null)) { ... The important thing to note is that Snowflake is not at all a special case; the detectTypeAndParseDescriptors method calls parseOneOrMoreDescriptors for many different descriptor types (with different delimiters): https://gitlab.torproject.org/tpo/network-health/metrics/library/-/blob/2b6…

2 2

Results per page: