fix: file a test's drop against the tick the world is on #113

Merged
sickday merged 1 commit from fix/world-test-tick into main 2026-08-04 14:25:34 +00:00
Owner

A test that writes tick: 0 when it drops something on the floor is stating
when the drop happened, and World.GroundItems files the despawn 300 ticks
after it. On a world that has been up for more than three minutes that pile is
born already overdue, so the sweep takes it before the assertion reads it.

That is why two tests passed alone and failed in the suite — 28 seconds of
world against 670:

  • World.FiremakingWorldTest, "a fire on a fire is refused from a pile
    already lying under the fire"
    : the pile it drops is gone by the time it
    looks.
  • World.Content.LightTest, "the loop over the real floor": the loop halts
    saying the logs have disappeared, because on the real floor they have.

Both read as flakiness and both are arithmetic.

The fix

Support.PlayerHost.join/2 already had the answer and threw it away.
World.join/2 states the tick it seats a player on — the same fact a real
session is given, and the tick World.Player.Host is seeded with — so the
reply now carries it and the firemaking test drops against it. The other 37
call sites take _tick.

For a test with no player to ask, Support.WorldClock.tick/0 reads the world's
own clock, which is the :sys.get_state/1 idiom this suite already uses in 72
places to wait for a tick to land. World.Content.LightTest and
World.ItemSpawnsWorldTest file their drops against it.

World.GroundItemsTest keeps its literals on purpose: there the ticks are the
subject rather than a timestamp — despawn_at == 300, expire(299) == []
and the arithmetic is what is being asserted.

Verified where the failure lives

Both defects are invisible to the file alone, so the whole suite is the oracle:
4275/4276, twice, the single red being the snapshot key list that is fixed
on fix/tick-snapshot-setup-key. Before this branch the same run was 4274/4276.

A test that writes `tick: 0` when it drops something on the floor is stating when the drop happened, and `World.GroundItems` files the despawn 300 ticks after it. On a world that has been up for more than three minutes that pile is born **already overdue**, so the sweep takes it before the assertion reads it. That is why two tests passed alone and failed in the suite — 28 seconds of world against 670: * `World.FiremakingWorldTest`, *"a fire on a fire is refused from a pile already lying under the fire"*: the pile it drops is gone by the time it looks. * `World.Content.LightTest`, *"the loop over the real floor"*: the loop halts saying the logs have disappeared, because on the real floor they have. Both read as flakiness and both are arithmetic. ## The fix `Support.PlayerHost.join/2` already had the answer and threw it away. `World.join/2` states the tick it seats a player on — the same fact a real session is given, and the tick `World.Player.Host` is seeded with — so the reply now carries it and the firemaking test drops against it. The other 37 call sites take `_tick`. For a test with no player to ask, `Support.WorldClock.tick/0` reads the world's own clock, which is the `:sys.get_state/1` idiom this suite already uses in 72 places to wait for a tick to land. `World.Content.LightTest` and `World.ItemSpawnsWorldTest` file their drops against it. `World.GroundItemsTest` keeps its literals on purpose: there the ticks are the subject rather than a timestamp — `despawn_at == 300`, `expire(299) == []` — and the arithmetic is what is being asserted. ## Verified where the failure lives Both defects are invisible to the file alone, so the whole suite is the oracle: **4275/4276**, twice, the single red being the snapshot key list that is fixed on `fix/tick-snapshot-setup-key`. Before this branch the same run was 4274/4276.
fix: file a test's drop against the tick the world is on
All checks were successful
ci / gates (pull_request) Successful in 51s
build / image (push) Successful in 14s
ci / gates (push) Successful in 57s
52a9c78549
A pile is swept 300 ticks after the one it was dropped on, so a test that
writes `tick: 0` drops something born already overdue on any world older
than three minutes. That is every run of the suite and no run of the file
alone: World.FiremakingWorldTest lost its pile to the sweep before the
assertion, and World.Content.LightTest's real-floor loop halted saying the
logs had disappeared. Both read as flakiness and both are arithmetic.

Support.PlayerHost.join/2 had the answer and threw it away — World.join/2
states the tick it seats a player on, which is the same fact a real
session is given, so the reply now carries it. For the tests with no
player to ask, Support.WorldClock.tick/0 reads the world's own clock.

World.GroundItemsTest keeps its literals: there the ticks are the subject
rather than a timestamp, and its assertions are the arithmetic itself.

Verified by the whole suite rather than by the files alone, which is the
only place either failure was ever visible: 4275/4276, the one red being
the snapshot key list fixed on its own branch.
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Revenant/Server!113
No description provided.