Bug Reporting for Games With Crafting Queues

Crafting queues let players start work and walk away, which means the game has to correctly account for time the player was not watching, and that is where the bugs live. Players report that a craft never finished, that offline progress gave too little or too much, that a finished item is simply gone. Each of these is a question about the queue state and the timestamps that drive completion: when each item started, when it should finish, and when the queue was last processed. Crafting queues are time-driven state machines, so their bugs are best diagnosed as timelines. This post covers what goes wrong in crafting queues and what to capture so a stuck-craft report becomes a replayable sequence.

Crafts that never complete

The signature crafting bug is the craft that should have finished but did not: the timer hit zero and nothing happened, or the queue stalled and later items never started. This is almost always a problem in the completion check, the thing that compares the current time to each item's finish time and advances the queue. A completion that only runs while the crafting screen is open, or that processes one item per tick and falls behind, or that silently fails when an inventory is full, all leave items stuck. The player reports a frozen queue, and the cause is in when and how completion is evaluated.

Diagnosing this requires the queue state and the timing: each queued item with its start and expected finish time, the timestamp the queue was last processed, and the current time. When a report shows an item whose finish time passed hours before the last-processed time but is still pending, you have found a completion check that is not running or not advancing. The inventory-full case shows up as a completed craft that could not deposit its output. Without the queue and the timestamps, a stuck queue is a shrug, and with them it is a specific failure at a specific step you can reproduce.

Offline progress math

The hardest crafting bugs involve offline progress, the calculation that fast-forwards the queue to account for time the game was closed. Get it wrong and players get too little, completing fewer crafts than the elapsed time warrants, or too much, exploiting a clock change to complete more. The math depends on the elapsed time between the last processed timestamp and now, which itself depends on which clock you trust. Using the device clock invites manipulation and timezone drift, while using the server clock requires a round-trip the offline path may not have made.

To catch offline bugs, capture the last-processed timestamp, the current device clock, the server time if available, and the elapsed time the game actually used in its calculation, alongside how many crafts it credited. When a report shows eight hours elapsed but only two crafts credited on a one-hour recipe, you have a capping or computation bug. When it shows more crafts than the elapsed time allows, you have a clock-trust bug. Capturing the elapsed value the game computed, not just the raw timestamps, is what lets you see whether the bug is in reading the clock or in the math that consumes it.

Items that vanish at completion

A particularly trust-damaging crafting bug is the completed item that disappears: the craft finished, consumed its ingredients, and produced nothing the player can find. This usually happens at the deposit step, where the output is added to inventory. A full inventory, a stack-size limit, a race between the deposit and another inventory operation, or a completion that ran twice and consumed ingredients twice can all leave a player out their materials with nothing to show. The player reports a lost item, and underneath is a failed or doubled deposit at the boundary of completion.

Capturing the completion as an event with its inputs and outputs makes this tractable. Record which ingredients were consumed, what output was produced, and whether the deposit succeeded, along with the inventory state at that moment. When a report shows ingredients consumed but no output deposited and a full inventory, you have isolated the deposit-failure case and can decide whether to block the craft, queue the output, or refund. The doubled-completion case shows up as ingredients consumed twice for one queued craft. Treating completion as a logged transaction is what separates a real loss from a player who misremembered.

Designing the crafting report payload

Settle on a queue snapshot that ships with every crafting report. Include the full queue with each item's recipe, start time, and expected finish time, the last-processed timestamp, the device and server clocks, the elapsed time used in the last offline calculation and the crafts it credited, and the recent completion events with their consumed and produced items. With that you can replay the queue against your completion logic from the last-processed point and see exactly where it diverged, whether a craft stalled, the offline math miscounted, or a deposit failed.

Keep the snapshot bounded to the active queue and recent completions so it stays cheap to attach automatically. The aim is that a player frustrated by a stuck or lost craft just hits report, and you receive the timeline that explains it without needing to ask when they last opened the game. Consistent fields enable aggregation: counting stuck-queue reports that share an inventory-full condition reveals a deposit bug, and counting offline-progress reports clustered on a platform or clock condition isolates where the elapsed-time calculation is going wrong for many players.

Setting it up with Bugnet

Bugnet captures your crafting queue state automatically when a player taps the in-game report button, so the queue, timers, last-processed timestamp, clocks, and recent completions arrive as custom fields with no upload code. A player whose craft is stuck or whose item vanished just reports it, and you receive the queue timeline that explains it, plus the device and platform context, including the device clock that often explains an offline-progress discrepancy. Because the timing data arrives with the report, you avoid the futile exercise of asking a player exactly when they last had the game open.

Crafting bugs cluster around specific recipes, queue depths, and clock conditions, and occurrence grouping makes that a clear priority signal. Bugnet folds duplicate reports into one issue with a count, and you can filter by a recipe or completion_state custom field to find the systemic cause. When forty stuck-craft reports all share the same recipe and a full inventory, that single issue rises by occurrence count and points at a deposit-handling bug, so you fix the deposit path once instead of triaging forty near-identical reports of a queue that froze and ate the materials.

Testing time-driven queues

Once reports carry the queue and timing, you can write tests that pin a clock and replay the queue: advancing time past a finish must complete exactly one craft, a full inventory must handle the output predictably rather than dropping it, and an offline gap must credit exactly the number of crafts the elapsed time and recipe allow. Each fixed crafting bug becomes a permanent assertion, which matters because time-driven queues are full of boundary and clock-trust cases that are easy to break and slow to notice until materials start disappearing.

Test the offline path with deliberately hostile clocks: a clock jumped forward, a clock set back, a huge elapsed gap, and a session that spanned a server outage. Keep capturing real queue states from the field so your tests cover the recipe mixes and queue depths players actually build, which are never the tidy ones you would write by hand. Crafting queues are a core loop in survival and idle games, and treating their bugs as replayable timelines is what lets a small team keep that loop reliable as recipes and production systems multiply.

A stuck craft is a timeline, not a frozen icon. Capture the queue, the timestamps, and the completion events and a lost item becomes a sequence you can replay and fix.