Surfaced by the high-effort retrospective /review of PR #17 (v0.4.0 DB→engine plugin orchestrator rename).
Symptom
allocateEngines (internal/cli/create.go) requires and only ever allocates/writes the "main" role:
mainRange, ok := eng.PortRanges["main"]
if !ok {
// Λ-7.4 will iterate every role; for now we require
// "main" so single-port plugins boot. A multi-port
// engine that declares no "main" is a config error.
return nil, fmt.Errorf("config: engines[%s].port_ranges must declare 'main' (multi-port allocation lands in Λ-7.4)", eng.Kind)
}
The Up() call site (startEngines, same file) also hardcodes a single-element PortSpec slice: []engineapi.PortSpec{{Role: "main", Port: port}}. Neither has changed since.
A .bough.yaml declaring a genuinely multi-port engine (port_ranges: {amqp: [...], management: [...]}, no main key — the exact shape internal/config/config.go's Engine.PortRanges doc comment and docs/PLUGIN_AUTHOR_GUIDE.md invite plugin authors to use) fails bough create outright with the message above. Even adding a main role as a workaround doesn't help — only main's port is ever passed to the plugin's Up() call.
Why it matters
This PR's own CHANGELOG.md v0.4.0 entry states, present tense, that "the host allocates a deterministic port per role" for multi-port engines. conformance/mock_plugin's modeMultiPort and the conformance suite's multi-port-role handling already exist and are exercised in tests (see #17's related mock_plugin fixes) — but the real bough create path this is all supposedly wired into cannot drive it. Anyone reading the CHANGELOG or the plugin author guide and following it hits a wall.
The Λ-7.4 label in the error message shows this was tracked as a known follow-up at the time — a grep across the repo confirms no later PR ever implemented it.
Scope
This is a real feature gap, not a small bug — closing it needs:
allocateEngines to iterate every declared PortRanges role, not just main (allocate + register each under <kind>.<role>)
- The
Up() call site to build the full multi-role []engineapi.PortSpec, not a hardcoded single entry
- Verification against an actual multi-port plugin (mock_plugin's
modeMultiPort is the existing harness) end-to-end through the real CLI, not just the conformance suite
- A CHANGELOG correction either way (either implement it, or soften the v0.4.0 entry to "the on-wire contract supports it;
bough create wiring is pending")
Not attempting a quick fix here — this needs its own design/implementation pass, not a bundled retrospective-review patch.
Surfaced by the high-effort retrospective
/reviewof PR #17 (v0.4.0 DB→engine plugin orchestrator rename).Symptom
allocateEngines(internal/cli/create.go) requires and only ever allocates/writes the"main"role:The
Up()call site (startEngines, same file) also hardcodes a single-elementPortSpecslice:[]engineapi.PortSpec{{Role: "main", Port: port}}. Neither has changed since.A
.bough.yamldeclaring a genuinely multi-port engine (port_ranges: {amqp: [...], management: [...]}, nomainkey — the exact shapeinternal/config/config.go'sEngine.PortRangesdoc comment anddocs/PLUGIN_AUTHOR_GUIDE.mdinvite plugin authors to use) failsbough createoutright with the message above. Even adding amainrole as a workaround doesn't help — onlymain's port is ever passed to the plugin'sUp()call.Why it matters
This PR's own
CHANGELOG.mdv0.4.0 entry states, present tense, that "the host allocates a deterministic port per role" for multi-port engines.conformance/mock_plugin'smodeMultiPortand the conformance suite's multi-port-role handling already exist and are exercised in tests (see#17's related mock_plugin fixes) — but the realbough createpath this is all supposedly wired into cannot drive it. Anyone reading the CHANGELOG or the plugin author guide and following it hits a wall.The
Λ-7.4label in the error message shows this was tracked as a known follow-up at the time — agrepacross the repo confirms no later PR ever implemented it.Scope
This is a real feature gap, not a small bug — closing it needs:
allocateEnginesto iterate every declaredPortRangesrole, not justmain(allocate + register each under<kind>.<role>)Up()call site to build the full multi-role[]engineapi.PortSpec, not a hardcoded single entrymodeMultiPortis the existing harness) end-to-end through the real CLI, not just the conformance suitebough createwiring is pending")Not attempting a quick fix here — this needs its own design/implementation pass, not a bundled retrospective-review patch.