Repository navigation
group-loot roll never resolves on the local 3-db dev stack: votes land, SMSG_LOOT_ROLL_WON never sent #84
Description
Found during the #81 4c A/B runs. The wire-harness test-group-loot.sh scenario fails at the resolve step on the local lyracore dev up stack (3 databases: lyracore + kalimdor + realm-core, world-imported node):
- START_ROLL and ROLL_VOTE relays deliver (both clients see the roll window and vote Greed)
- SMSG_LOOT_ROLL_WON never arrives; a
game_grouprow lingers after teardown
Bisected: NOT a 4c regression. Fails identically with the branch gateway flag-off, flag-on, and with a pre-4c gateway build (private-history commit) on the same stack. Schedules were armed (debug_repair_after_publish on all three dbs — the pinned lyracore-cli predates the publish-arming fix, so dev up alone leaves them dead; worth knowing for any local repro).
Suspect surface: the roll SETTLE path on this topology — the world-shard staging roll promotion / realm-core resolve (world::loot::relay_tick, settle_loot_roll). The bot suite historically ran this green on an imported single-db node, so the 3-db shape (or something the dev-up fixture still lacks) is the delta to chase.
Repro: lyracore dev up + world import + arm schedules + provision TEST/TEST2 with chars Ginger/dfsdfsd, then run the wire harness's materialized test-group-loot.sh scenario via the suite runner (adapter runner in the private working origin). Clean game_group*/game_loot_roll* between runs — a failed run's lingering group row makes the NEXT run fail earlier (no SMSG_GROUP_INVITE), which reads like a different bug.
Scope widened (2026-08-09) — same local-3-db-stack bucket: the end-of-arc full-suite run found test-party-brains fails deterministically here too — tank: no wolf melee row ever on the tank (the wolf never opens melee on the bot tank, so the taunt-hold assert reads 0). Reproduced standalone off-load, and IDENTICALLY with LYRACORE_SHARED_CALLS on and off on the 4c/4d branch build — flag-independent, module/stack-side. bot_deadmines also timed out its kill (300s) under full-suite load on the same stack; walkmelee/eventai_cast/combat_regen all pass, so creature combat generally works — it is specifically the bot-party combat paths. Historically green on the work-loop's imported single-db node with the main module, so the delta to chase is branch-module-on-3-db-topology vs that baseline.
Migrated 2026-08-11 from the private tracker (spacetime-core#477).
Activity
Mathih13 commentedon Sep 8, 2026
PR #474 merged a reproduced Gateway retry defect. A failed
settle_loot_rollrequest used to advance the completion marker, so the next tick skipped that result. The marker now stays put on failure while healthy Shards continue. The regression failed on the previous Gateway and passes with the fix; the full Gateway suite and CI passed.This does not establish the cause of the missing
SMSG_LOOT_ROLL_WONor bot-party combat failures reported here. The issue remains open for a current three-Shard reproduction.Recovery after the one-second Group Event lifetime also remains open. A longer retry cannot safely identify loot by corpse GUID and slot alone because a later corpse can reuse both. The next source Ticket requires the originating Module and exact
CorpseLootrow identity to survive promotion and resolution, plus durable settlement and acknowledgment across Gateway restart. Its regression cases must cover two Gateways, uncertain transport results, a later drop at the same corpse/slot, a matching corpse/slot in another Module, full inventory and absent source rows.The maintained delivery report tracks this remaining design and the original acceptance separately. No live Realm was accessed for this fix.
Mathih13 commentedon Sep 23, 2026
#531 fixes the original incident, and it is merged. The Headless Client voted as soon as
SMSG_LOOT_START_ROLLarrived. That was before the Gateway's 200 ms relay had copied the roll to Realm-core, so Realm-core refused both votes ("no roll open on that item"). At the 60 s deadline every vote counted as a pass.run_votenow flushes pending promotions first.Evidence on a local 4-database
dev upstack:main: failed 2 of 2.What remains open here:
test-party-brains,bot_deadmines) needs the playerbots Package fromLyraCoreProject/packages, which a plain checkout does not include. It is still unverified on the multi-shard stack.test-group-loot.shfails earlier on currentmain. A creature drops loot only after a player damages it, and the scenario kills the wolf without damage. It needs adebug_apply_damage <wolf> 1 <player>step before each kill, and then a pin bump.Mathih13 commentedon Oct 8, 2026
The loot vote race is fixed: run_vote flushes pending promotions before it votes, and the durable test a_vote_on_a_staged_roll_reaches_realm_core_after_its_promotion proves it. The bot combat and wire-harness threads belong to other repositories; file them there if they still happen.