ax dashboard reads only the SQLite event log and ignores Postgres configuration
- Dominant language
- Go
- Stars
- 2k
- Forks
- 120
- PR merge metrics
- No merged PRs in 30d
Description
### What
`ax dashboard` always opens the SQLite event log and has no Postgres code path. When the controller is configured to use a Postgres event log (`eventlog.postgres.dsn` / `AX_EVENTLOG_DSN`), the dashboard does not read it and shows no data.
### Where
`cmd/ax/dashboard.go` (`runDashboard`):
- Reads `cfg.EventLog.SQLiteConfig.Filename` unconditionally (`dashboard.go:76`)
- Opens the DB with `sql.Open("sqlite", dbPath)` (`dashboard.go:83`)
- Runs `CREATE TABLE IF NOT EXISTS ...` on that SQLite handle (`dashboard.go:95+`)
There is no branch that inspects `cfg.EventLog.Postgres`, unlike `ax serve`, which supports Postgres via `eventlog.postgres.dsn`.
### Impact
For a Postgres-backed deployment, `ax dashboard`:
- ignores the configured Postgres DSN,
- opens/creates an empty SQLite database at the (possibly empty/default) `SQLiteConfig.Filename`,
- silently renders an empty conversations/executions list,
with no error indicating the store mismatch.
### Repro
1. Configure `ax.yaml` with a Postgres event log:
```yaml
eventlog:
postgres:
dsn: ${AX_EVENTLOG_DSN}
```
2. Run the server and create a conversation (`ax serve` + `ax exec --server ...`).
3. Run `ax dashboard --config ax.yaml`.
4. The dashboard is empty; the Postgres data is never read.
### Expected
Either:
- `ax dashboard` reads the same event log backend as `ax serve` (i.e. support Postgres), or
- it fails fast with a clear error when a non-SQLite event log is configured, instead of silently opening an empty SQLite DB.
### Notes
Appears to be a known limitation. Filing to track adding Postgres support (or an explicit guard/error).
Contributor guide
Research direction
Start in cmd/ax/dashboard.go at runDashboard and trace how the SQLite filename, database handle, and table setup are selected. Compare this with the Postgres configuration path used by ax serve, including eventlog.postgres.dsn. Done means the dashboard uses the configured event log backend or fails fast with a clear error instead of showing an empty SQLite-backed view.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, postgresql, sqlite
- Domain
- backend, cli, databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100