[davidkopp]

In a GitHub Codespace, a measurement run with optimizations enabled writes this to system_logs:

Error: Redis store_artifact failed
Exception (ConnectionError): Error -2 connecting to green-coding-redis-container:6379. Name or service not known.

Cause

optimization_providers/base.py calls get_phase_stats_single from api/scenario_runner in the runner process instead of over HTTP, and that function ends with store_artifact(ArtifactType.STATS, ...), which connects to the redis host from config.yml: green-coding-redis-container:6379.

On the host that name only resolves through /etc/hosts. lib/install_shared.sh writes 127.0.0.1 green-coding-postgres-container green-coding-redis-container, .devcontainer/on-start.sh wrote the postgres name only. So in a codespace postgres resolves and redis does not: the error only shows up in codespaces, only on the optimizations path, and it survives container restarts.

What is not the cause

Container networking and startup order, measured in the codespace while the errors were being logged:

• getent hosts inside green-coding-gunicorn-container resolves both green-coding-postgres-container (172.18.0.2) and green-coding-redis-container (172.18.0.4).
• all three containers are on green-metrics-tool_default.
• redis: RestartCount=0, exit code 0, not OOM-killed; it started 90 ms before gunicorn and the last error was logged 81 s after that start.
• the 127.0.0.1:6379 publish in docker/compose.yml is host-only and is not used by this path.

--skip-optimizations hides the error because optimization_providers/base.py is then never called.

Change

on-start.sh writes the same hosts entry as install_shared.sh.

Verification

Verified in a codespace with the hosts entry in place. The rows from before the fix stay in the table, so the check is that a run with optimizations enabled adds none:

date
docker exec green-coding-postgres-container psql -h 127.0.0.1 -p 9573 -U postgres -d green-coding \
  -c "select created_at from system_logs where message ilike '%store_artifact%' order by created_at desc limit 5;"

Mon Nov  9 12:16:42 UTC 2026
          created_at
-------------------------------
 2026-11-09 12:55:44.446523+01
 2026-11-09 12:39:30.759096+01
 2026-11-09 12:35:51.869978+01
 2026-11-09 11:27:38.904498+01
(4 rows)

The run finished at 12:16:42 UTC, the newest error row is 12:55:44+01 (= 11:55:44 UTC), 21 minutes before it. Non-codespace installs were already fine: a local install has the combined line in /etc/hosts and both names resolve to 127.0.0.1.

Impact of the bug

Lost cache write plus one error row per run. store_artifact catches the exception, so the phase stats are still computed and returned and the optimizations still run.

---

Created by pi (AI agent), reviewed by me.

---

^{Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need.}

[ArneTR]

Thanks for the PR!

Can you let me know:

• Why did this error occur? Did you manually activate optimizations or are optimizations wrongly activated by default?

If they have been manually activated: What do you want to find out with the optimizations in a codespace? Technically the codespace is a quite unreliable env in regards to performance guarantees. So many optimizations provide unreliable results.

I want to better understand the use-case to decide if optimizations should be hard blocked and not even be possible to enable, or maybe enabled by default but warnings added.

[ArneTR]

@ribalba Did you also encounter this when you recently overhauled the Codespace Implementation?

[davidkopp]

The GitHub Codespaces environment is used by me for trainings. I would like to use GMT with the default runner switches as far as possible. I do not have the time the explain all switches and I want to avoid any warnings. If I skip optimization with --skip-optimizations there is this warning:

I want to avoid this warning in a training situation.

So I do not need the optimization feature at all in GitHub Codespaces. If I can disable it without getting the warning, I would do this.

[ArneTR]

That helps a lot!

How would you feel if we disable optimizations fetching and make it on request only? It would then be similar to the Logs atm. which are only requested if the user clicks:

This setting can be optionally selected as to always load them if the user requested it in the settings.

[davidkopp]

Fetching optimizations only on request would fix the warning issue for me. But I still have to set --skip-optimizations as a runner switch, correct? That is ok for me. Even better could be a flag in config.yml that is always set in GitHub Codespaces that entirely disables the optimization feature.

[ArneTR]

Sounds good. We can make optimizations opt-in. Actually something we have discussed internally for a while.

Do you have a date until you need this patch, so we can plan best when to prioritze this?

[davidkopp]

The next training is scheduled for the 7th December (not sure yet if there are enough participants).
This requirement is not so important, so no real deadline from me.

Should we close this PR?