● ## Issue 1: Hardcoded BASE_URL breaks demo scripts on local machines
All three demo scripts (demo-catalogue-service.sh, demo-notifications-service.sh,
demo-dashboard-service.sh) hardcode BASE_URL="http://localhost", which only works in GitHub
Codespaces.
On a local machine, k3d runs Kubernetes inside Docker. Traefik is not on localhost — it's behind a
Docker port bridge (8123:80@loadbalancer). So every curl call fails with HTTP 000 (connection
refused).
Why it works in Codespaces:
In Codespaces, the k3d cluster maps Traefik with 80:80@loadbalancer directly onto the VM. Since the
terminal runs on that same VM, http://localhost resolves correctly.
Locally, the correct URL is http://localhost:8123 — but even this is fragile, since 8123 is just an
arbitrary port hardcoded in setup-tutorial.sh. If that port is occupied and the cluster is created with
a different port, the demo scripts break again.
Issue 2: Silent Failures in notifications and dashboard scripts
The execute_with_retry function in the notifications and dashboard scripts checks success like this:
if [ $exit_code -eq 0 ] && ! echo "$output" | grep -q "detail"; then
When curl can't connect, it exits with code 0 and returns empty output. Both conditions pass — so the
script prints ✓ created successfully! even though nothing was created.
The catalogue script already handles this correctly by checking the actual HTTP status code via -w
"\n%{http_code}". This makes the behaviour inconsistent across the three scripts.
● ## Issue 1: Hardcoded BASE_URL breaks demo scripts on local machines
All three demo scripts (
demo-catalogue-service.sh,demo-notifications-service.sh,demo-dashboard-service.sh) hardcodeBASE_URL="http://localhost", which only works in GitHubCodespaces.
On a local machine, k3d runs Kubernetes inside Docker. Traefik is not on
localhost— it's behind aDocker port bridge (
8123:80@loadbalancer). So every curl call fails with HTTP 000 (connectionrefused).
Why it works in Codespaces:
In Codespaces, the k3d cluster maps Traefik with
80:80@loadbalancerdirectly onto the VM. Since theterminal runs on that same VM,
http://localhostresolves correctly.Locally, the correct URL is
http://localhost:8123— but even this is fragile, since8123is just anarbitrary port hardcoded in
setup-tutorial.sh. If that port is occupied and the cluster is created witha different port, the demo scripts break again.
Issue 2: Silent Failures in notifications and dashboard scripts
The
execute_with_retryfunction in the notifications and dashboard scripts checks success like this:When curl can't connect, it exits with code 0 and returns empty output. Both conditions pass — so the
script prints ✓ created successfully! even though nothing was created.
The catalogue script already handles this correctly by checking the actual HTTP status code via -w
"\n%{http_code}". This makes the behaviour inconsistent across the three scripts.