refactor(demo): run native demo without Docker

[sveitser]

Replace the five Docker-backed process-compose services with native processes so just demo-native needs no Docker daemon:

• demo-l1-network: custom geth-l1 image -> native anvil (from foundry)
• espresso-node-db-0/1: docker postgres -> scripts/run-postgres
• keydb: docker keydb -> native redis-server
• telemetry-collector (vector) and block-explorer: dropped

flake.nix adds redis and bumps postgresql_16 -> postgresql_18. cleanup-process-compose drops the docker compose teardown and reaps anvil/postgres/redis-server.

[gemini-code-assist]

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

[claude]

Claude finished @sveitser's task in 3m 22s —— View job

---

Review: run native demo without Docker

Nice cleanup — replacing the Docker-backed services with native processes makes just demo-native self-contained, and the changes are internally consistent. I verified the key wiring and it holds together:

• ✅ anvil accounts match .env — .env uses the standard foundry mnemonic (test test test … junk), which is exactly anvil's default, so --accounts 20 --balance 1000000000 funds the deployer/prover/builder accounts the deploy scripts expect.
• ✅ redis password is consistent — --requirepass 'changeme!' matches all four CDN consumers (redis://:changeme!@localhost:6379).
• ✅ WS-on-HTTP-port change is correct — anvil serves WS and HTTP on the same port, so pointing ESPRESSO_L1_WS_PROVIDER at ESPRESSO_L1_PORT is right.
• ✅ Removed vars left in .env/docker-compose.yaml (ESPRESSO_L1_WS_PORT, telemetry ports, block-explorer port) are still used by the untouched docker-compose.yaml path, so keeping them is correct.
• ✅ intentionally-unreachable-telemetry-endpoint already existed for espresso-node-0 on main; extending it to nodes 1 & 3 (now that vector is dropped) is consistent with the existing convention.
• ✅ postgres readiness probe correctly gates on the espresso DB via psql … SELECT 1 — a good fix for the "ready before createdb runs" race, which is why dropping success_threshold: 2 is safe here.
• ✅ run-postgres shutdown — binds to 127.0.0.1 only, uses fast-shutdown (kill -INT), and the double-wait mirrors scripts/demo-native so postgres isn't orphaned. Well documented.
• ✅ cleanup-process-compose — anvil/postgres/redis-server added to NATIVE_PROCESSES and the docker teardown removed, matching the new service set.

Findings (all minor / non-blocking)

1. run-postgres can hang if shutdown arrives during startup — if SIGTERM/SIGINT hits while still in the until pg_isready loop, the trap kills postgres but the loop then spins forever and never reaches wait. Narrow window; suggested a flag-based break inline.
2. run-postgres usage doc — says the DATADIR must be an "existing empty" directory, but the script relies on initdb creating it. Minor wording fix suggested inline.
3. anvil/redis bind to 0.0.0.0 — consumers all use localhost and postgres is already 127.0.0.1-only; consider --host 127.0.0.1 / --bind 127.0.0.1 for consistency. Optional.

Nothing here blocks merge. Assuming just demo-native was run end-to-end (contract deploy + nodes reaching process_healthy), this looks good to ship.

[claude]

Startup-time shutdown can hang this script. The trap is installed before this readiness loop, but if SIGTERM/SIGINT arrives while we're still in the until pg_isready loop, the trap fires kill -INT on postgres and postgres starts shutting down — after which pg_isready will never succeed, so this loop spins forever and the wait lines below are never reached. process-compose then has to SIGKILL on teardown.

This is a narrow window (only during startup, before the DB is ready), so it's minor, but you can make shutdown deterministic by breaking out when a shutdown was requested, e.g. set a flag in the trap and check it:

shutting_down=0
trap 'shutting_down=1; kill -INT "${pg_pid}" 2>/dev/null' TERM INT

until pg_isready -h 127.0.0.1 -p "${port}" >/dev/null 2>&1; do
  [[ "${shutting_down}" -eq 1 ]] && break
  sleep 0.5
done

[claude]

Minor doc nit: the usage says DATADIR Existing empty data directory to initialize and use, but the script actually relies on initdb creating the directory (the caller passes ${ESPRESSO_BASE_STORAGE_PATH}/pg0, which doesn't exist yet). Only the parent needs to exist. Consider rewording to "Data directory to initialize (created if missing; must be empty if it exists)" so it's clear the dir need not pre-exist — and that re-running against a populated dir would fail initdb.

[imabdulbasit]

I haven't looked through all of the code but since the native demo works, so I'm approving it.