Skip to content

test(services): a port test that asks about MixEngine and not about the runner (T34c) - #26

Merged
haiquang9994 merged 1 commit into
masterfrom
t34c-ports-tests-stop-assuming-the-machine
Aug 24, 2026
Merged

test(services): a port test that asks about MixEngine and not about the runner (T34c)#26
haiquang9994 merged 1 commit into
masterfrom
t34c-ports-tests-stop-assuming-the-machine

Conversation

@haiquang9994

Copy link
Copy Markdown
Collaborator

test (windows-latest) went red on master at 8b9a394. fakeservice@second was
given 41000 and @main a number above it, so second == first + 1 failed.

The allocator was right. It searches from the recipe's wish every time, so a
machine holding 41000 while @main was created and releasing it before
@second leaves exactly that pair. And nothing in this workspace binds
41000
— the fixture recipe says so of itself, and every other bind in the
tree asks for port 0 — so what held it was the runner. The test was asserting a
property of the machine.

What is asserted instead

At the end-to-end layer, only what survives a busy machine:

  • the three instances get three different ports
  • every one of them is inside [41000, 41000 + SEARCH]
  • the one that could not have the number it wanted is told the number it
    wanted
    , not the number it got — the old assertion compared it against a
    port that may itself have moved, so it was wrong the same way

The exact-successor claim moves rather than disappears

a_moved_service_is_given_the_very_next_port in
mixengine_core::services::ports takes two consecutive free ports out of the
24000 band through a new a_free_run, holds the first and asserts the
allocation is the second. a_free_port is that call with a run of one. A band
somebody controls is the only place the letter of the rule can be held to.

mixengine-daemon's packages suite carried the same premise one assertion
along — "the fixture recipe's preferred port, free in a home of its own"
and free in a home of its own was never the question. It asks for a port now.

Measured

With a listener held on 41000 for the whole run, the rewritten test passes; the
old one could not have. CI green on all ten jobs.

…he runner (T34c)

`test (windows-latest)` went red on master at 8b9a394:
`fakeservice@second` was given 41000 and `@main` a number above it, so
`second == first + 1` failed. The allocator was right. It searches from the
recipe's wish every time, so a machine holding 41000 while `@main` was created
and releasing it before `@second` leaves exactly that pair — and **nothing in
this workspace binds 41000**, which the recipe says of itself, so what held it
was the runner. The test was asserting a property of the machine.

What survives a busy machine, and is asserted instead: the three instances get
three different ports, all inside the band `[41000, 41000 + SEARCH]`, and the
one that could not have the number it wanted is told the number it wanted
rather than the number it got. Measured rather than argued: with a listener
held on 41000 for the whole run, the rewritten test passes and the old one
could not have — it expects `moved_from.preferred` to equal a port that moved.

The exact-successor claim is not dropped, it moves to where a band belongs to
somebody: `a_moved_service_is_given_the_very_next_port` takes two consecutive
free ports out of the 24000 window `a_free_run` now hands out, holds the first
and asserts the allocation is the second. `a_free_port` is that call with a run
of one.

`mixengine-daemon`'s packages suite carried the same premise one assertion
along — "the fixture recipe's preferred port, free in a home of its own" — and
free in a home of its own was never the question. It asks for a port now.
@haiquang9994
haiquang9994 merged commit 01fe6ab into master Aug 24, 2026
10 checks passed
@haiquang9994
haiquang9994 deleted the t34c-ports-tests-stop-assuming-the-machine branch September 5, 2026 20:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant