Profile [env.*] cannot override LOCALSTACK_HOST (launcher value appended last)
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
Research direction
Start in internal/container/start.go around the environment assembly at lines 266–296; compare the SF_S3_ENDPOINT guard and MAIN_CONTAINER_NAME warning with how LOCALSTACK_HOST is appended. Check nearby tests for container environment construction, then add coverage for a profile-provided LOCALSTACK_HOST. Done means the profile value is honored or a clear warning explains that it is ignored, with the chosen behavior tested.
Written by the indexing model from the issue text.
Description
Observed
Setting LOCALSTACK_HOST in a config [env.*] profile has no effect. The container receives the variable twice — the profile value first, lstk's computed value second — and Docker's last-wins semantics keep lstk's. docker inspect on a type = "snowflake" container started with a profile containing LOCALSTACK_HOST = "sf.example.test:4599" shows both entries; the emulator sees localhost.localstack.cloud:4599. Nothing warns that the profile value was dropped.
Where
internal/container/start.go on main (d9c83037):
:276env := resolvedEnv— the profile's variables come first;:281-285env = append(env, "GATEWAY_LISTEN=…", "MAIN_CONTAINER_NAME=…", "LOCALSTACK_HOST="+endpoint.Hostname+":"+c.Port)— lstk's own value is appended unconditionally after them.
The two neighbours already handle this collision: SF_S3_ENDPOINT (:292) is appended only when the profile did not set it (!envHasKey(resolvedEnv, "SF_S3_ENDPOINT")), and MAIN_CONTAINER_NAME (:266-275) emits a warning saying the profile value is ignored. LOCALSTACK_HOST does neither, so the profile value vanishes silently. (A LOCALSTACK_HOST exported in the host shell does win, because hostEnv is appended at :296 after lstk's line — so the two configuration channels behave differently.)
Context
Recorded in September 2026 while diagnosing a snowflake-next result-chunk 404 under lstk (the emulator advertised the host lstk injected but its hostname gate did not route it; that was fixed on the emulator side, which now routes any host it is told to advertise). For the default flow this is harmless: the value lstk injects, localhost.localstack.cloud:<published port>, is the right one. It only matters when a user needs a different advertised host — a non-loopback hostname for clients on other machines, or a reverse-proxy name — and reaches for the documented [env.*] mechanism to set it.
Expected
Either the profile wins — append lstk's LOCALSTACK_HOST only when the profile did not set it, with the same envHasKey guard SF_S3_ENDPOINT uses — or lstk warns that the profile value is ignored, as it does for MAIN_CONTAINER_NAME, and the config docs state that LOCALSTACK_HOST is launcher-owned.
Reproduce
[[containers]]
type = "snowflake"
port = "4599"
env = ["custom"]
[env.custom]
LOCALSTACK_HOST = "sf.example.test:4599"
lstk start, then docker inspect <container> --format '{{json .Config.Env}}' → both LOCALSTACK_HOST=sf.example.test:4599 and LOCALSTACK_HOST=localhost.localstack.cloud:4599, in that order; inside the container echo $LOCALSTACK_HOST prints the latter.
- Dominant language
- Go
- Stars
- 37
- Forks
- 8
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 37
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Similar issues
-
enhancement exporter/awss3 needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
open-telemetry/opentelemetry-collector-contrib#51905 · 1 comment ·
Maintainers usually reply within 1 day
-
area/docs theme/validation
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
a11y P1-significant
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
[correctness][missing-coverage][sort] Strict uniqueness checks lack numeric-key equivalence coverageOpen
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
infiniflow/ragflow#20625 · 1 reaction ·
Maintainers usually reply within 1 day