Panic when a game has multiple active campaigns with already claimed drops (null handling in stream.rs)

[Dasercom]

The program panics when a game in games.txt has multiple active drop campaigns, but one or more of them have already been fully claimed. The Twitch GQL API appears to return null for the claimed campaign (or for the entire game structure), which the retry! macro cannot handle.

Observed panic:

root@DietPi:~/TwitchDropSentryMulti# ./target/release/twitchdrops_miner --debug
[████████████████████████████████████████] 100% (1815/720 min) Initialization...
thread 'tokio-rt-worker' (6849) panicked at src/stream.rs:140:59:
Retry failed after MAX_ATTEMPTS attempts: TwitchError(JsonError(Error("invalid type: null, expected struct GameDrops", line: 0, column: 0)))
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Aborted

Steps to reproduce:
Add the following games to lists/games.txt (in priority order):

Overwatch
Grand Theft Auto V
Hunt: Showdown 1896

Ensure that:

• Overwatch has two active drop campaigns: one fully claimed (all drops received), the other still in progress (has unclaimed drops).
  Grand Theft Auto V has no active drops.
  Hunt: Showdown 1896 has at least one active drop.

• Run the program: ./target/release/twitchdrops_miner

Actual result
The program crashes immediately with the above panic.

Expected result
The program should gracefully handle the situation:

1. Detect that Overwatch has multiple campaigns, but only one has unclaimed drops.

2. → Remove the fully claimed campaign from the farming list.

3. Start farming Overwatch for the remaining unclaimed drops.

4. After that drop is claimed, check if any other campaigns remain for Overwatch.
   → If none, move to the next game in the priority list.

5. Skip Grand Theft Auto V (no active drops) with a warning.

6. Start farming Hunt: Showdown 1896.

7. After all drops in the list are claimed, the program should not exit. Instead, it should continue running and periodically re-check all games in games.txt for new campaigns (e.g., every 1–5 minutes).

Assumption

The error is likely caused by the program’s inability to handle multiple active campaigns for a single game, especially when one of them is already fully claimed. Twitch API may return null for the completed campaign, leading to a deserialisation failure in stream.rs.

There is currently no built‑in way to verify that the error is specifically caused by a game with already‑claimed drops. However, in testing, only Overwatch with two campaigns triggered the panic — suggesting that the combination of multiple campaigns + claimed drops is the root cause.

Additional considerations

Diagnostic logging: Adding a diagnostic log that shows the raw API response for each campaign would help users and developers identify which game/campaign is causing the issue.

Proposed fixes

• Replace all retry! macros in src/stream.rs with proper error handling (e.g., match + continue).

• In main.rs, remove the early exit when no active campaigns are found, so the program stays alive and keeps checking.

• Filter out fully claimed campaigns when processing timeBasedDrops (check self_drop.isClaimed).

• Reduce the re‑check interval to 1–5 minutes (configurable via config.json or an environment variable).

Feature request: improved Discord notifications

Currently, Discord updates are time‑based and can be spammy. I propose a more structured approach:

When farming starts for a game, send a single message in Discord stating:

Game name
Number of drops in the campaign (e.g., "2 drops available")
Name Drops1
Name Drops2
Estimated progress (e.g., "Drop 1: 45%")

Update the same message periodically (every configurable minutes, e.g., 5 or 10 minutes) — not by sending a new message, but by editing the existing one.
When a drop is received, mark it as completed (e.g., "✅ Drop 1: Claimed").
When all drops for the current game are claimed, post a new message about switching to the next game in the priority list.

This would make Discord notifications much cleaner, less spammy, and more informative.

Additional context

Running on Raspberry Pi Zero W (ARMv6) with DietPi OS.
Rust 1.97.1, compiled from source.

Performance note: I launched the application on a Raspberry Pi Zero W (ARMv6, 512 MB RAM). Compilation took approximately 4 hours. This is fine for a one‑time setup, but please keep this in mind for users with low‑power devices.

Thank you for considering this! I'm happy to test any patches or provide more details if needed. 🙌

[this-is-really]

Hi, thanks for the detailed and well-structured report - it makes triaging much easier.

To address the points:

1. The invalid type: null, expected struct GameDrops panic is actually not related to Overwatch having multiple campaigns. The root cause is that the Twitch GQL API occasionally returns null for that field, and I honestly don't yet know under what conditions this happens - in theory it shouldn't. I'll dig into it and try to patch this properly

2. Long compile times on the Raspberry Pi Zero W - since v1.0.8, Cargo.toml uses aggressive optimization settings (lto = "fat", codegen-units = 1) to improve runtime performance. This noticeably increases build time even on my own PC, so ~4 hours on a low-power ARMv6 device is expected. For devices like that, I'd recommend downloading the prebuilt release binary instead of compiling from source

Your other suggestions all sound reasonable - I'll look into them separately, likely rolling parts of it out in future releases

Thanks again for the feedback

[Dasercom]

Здравствуйте, спасибо за подробный и хорошо структурированный отчет — он значительно упрощает сортировку запросов.

Чтобы ответить на следующие вопросы:

1. Паникаinvalid type: null, expected struct GameDrops на самом деле не связана с наличием нескольких кампаний в Overwatch. Основная причина в том, что API GQL от Twitch иногда возвращает ошибку для этого поля, и я, честно говоря ,null пока не знаю, при каких условиях это происходит — теоретически этого быть не должно. Я разберусь с этим и постараюсь исправить это должным образом.
2. Длительное время компиляции на Raspberry Pi Zero W — начиная с версии 1.0.8, Cargo.tomlиспользуются агрессивные настройки оптимизации ( lto = "fat", codegen-units = 1) для повышения производительности во время выполнения. Это заметно увеличивает время сборки даже на моем собственном ПК, поэтому ожидаемое время сборки на маломощном устройстве ARMv6 составляет около 4 часов. Для таких устройств я бы рекомендовал загрузить предварительно собранный бинарный файл вместо компиляции из исходного кода.

Все остальные ваши предложения звучат разумно — я рассмотрю их отдельно и, вероятно, включу отдельные части в будущие релизы.

Спасибо еще раз за отзыв.

The code contained incorrect logic for processing Twitch Drops game campaigns. When there were two active campaigns for a single game, the program incorrectly considered both available for farming. It sent a request to the first (already fully completed) campaign and parsed its possible drops. However, since these items had already been received, they were missing from the JSON response from twitch_gql_rs when requesting inventory. Due to this discrepancy between the expected drop and the actual inventory, the program crashed during the execution of the retry! macro.

What was done:

1. Logic refactoring: The logic for determining active campaigns and filtering received items was completely rewritten.
2. Macro removal: All retry! macros that were causing crashes were replaced with safer and more flexible error handling.
3. Documentation: The code was thoroughly commented to simplify future support.

Special thanks to the DeepSeek neural network for helping me master the intricacies of the Rust language.

Current status and remaining limitations:
The program is successfully farming, but the drop_cache logic is still imperfect. Apparently, twitch_gql_rs cannot correctly match and cache items from the first (completed) campaign. Because of this, the program gets stuck on the stream of one game, not switching to other games, as it considers the first campaign to be unfinished. However, items from the second campaign are cached after successful farming.

(Workaround):
Currently, the only working solution for cache synchronization is to manually parse the Twitch inventory HTML page and manually add the acquired items to the drop_cache file.

Please, if you somehow manage to get the received items from the twitch inventory, let me know, I will provide my code and developments on this matter.

[this-is-really]

Please, if you somehow manage to get the received items from the twitch inventory, let me know, I will provide my code and developments on this matter.

Hi! Here's the method from twitch-gql-rs: get_inventory() returns the inventory object, where dropCampaignsInProgress → timeBasedDrops contains a self field with dropInstanceID. If dropInstanceID.is_some(), the drop has accumulated enough watch minutes and is ready to be claimed - this ID gets passed into the claim mutation.

let inv = client.get_inventory().await?;
 if let Some(campaigns_in_progress) = inv.inventory.dropCampaignsInProgress {
     for campaign in campaigns_in_progress {
         for time_based in campaign.timeBasedDrops {
             if time_based.self_drop.dropInstanceID.is_some() {
                 // claim / cache logic here
             }

             if time_based.self_drop.isClaimed {
                // the drop has been received. In this case, you can also check whether it is in the cache list
             }
         }
     }
 }

Similar logic already exists in my claim_drop function, but it only handles a single drop_id. I'm working on an update that collects all drops for a specific campaign by game_id