Changelog¶

All notable changes to the gigaflow CLI are documented here.

The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.

[0.5.0] - 2026-06-09¶

gigaflow ingest <trace.json> — one command from an OTel export to a Flow viewer link. Upload a local OTLP/JSON envelope or flat span array (- reads stdin); the backend auto-provisions a project, auto-detects the exporter, and runs Flow analysis in the background while the CLI polls and then prints/opens the /flow/{trace_id} viewer. No vendor account, datasource, or token minting needed. Flags: --exporter, --label, --no-wait, --no-browser. Unanalysable pastes surface the backend's typed rejection reasons verbatim.
gigaflow setup connection preflight. The wizard now tests the vendor connection before registering, with an interactive [r]etry / [e]dit / [q] save-&-quit loop; config is always saved so gigaflow sync can be retried later without re-running setup.

gigaflow sync prints direct per-trace viewer links for the newest synced traces (capped at 5) instead of only the dashboard root.

Vendor onboarding docs decoupled from the dev/API flow; Arize host prompt reframed around Phoenix's database rather than gigaflow.

gigaflow setup no longer looks frozen during sync. Step 6 now prints a Syncing… progress line before the blocking sync request, and the sync POST gets a generous 120s read timeout instead of the 30s default tuned for quick calls — so a first full sync of a large dataset no longer fails with a cryptic Sync failed (None): {'error': 'The read operation timed out'}. On a genuine timeout the wizard now explains the sync may still be running on the backend and to re-run gigaflow sync.

The "could not connect to the source database" hint is now vendor-neutral (no longer Arize-specific) when the Docker host is misconfigured.

Datasource registration now authenticates with the GigaFlow backend key (the Step-1 key sent as Authorization: Bearer), not the vendor key — the vendor key still travels in the request body for the backend to read the upstream source.

gigaflow setup is now a guided, login-based flow. It no longer prompts for a backend URL or an API key:
Step 1 asks how you want to provide configuration — enter values interactively (recommended) or load a gigaflow.env file — with a link to the new gigaflow.env reference.
The backend defaults to the hosted service; developers override it with --backend / $GIGAFLOW_BACKEND_URL (shown as a Using backend: notice).
Setup signs you in automatically (waitlist email login) instead of asking for an API key. A dev key (--api-key / $GIGAFLOW_API_KEY) still bypasses login, and gigaflow login / logout / whoami remain available.
The project step explains what a project is and suggests a name (vendor-derived where available, otherwise default) instead of silently using a vendor name.
The vendor menu shows a short description per tracing tool and links each vendor's setup docs.
The wizard no longer writes api_key to ~/.gigaflow/config.json; the session token lives in ~/.gigaflow/credentials.json.

New docs page: The gigaflow.env file, documenting every recognized configuration key.

The CLI now defaults to the hosted backend (https://api.gigaflow.io/api/v1), so pip install gigaflow && gigaflow login works out of the box.

Per-user accounts: gigaflow login / logout / whoami. login opens a browser sign-in (email + password) and captures the session back to the CLI via a one-shot local callback; credentials are stored in ~/.gigaflow/credentials.json (mode 0600) with automatic token refresh.
Logged-in uploads are attributed to your account; the web UI shows only your traces. Credential precedence: explicit --api-key > env > logged-in user token > saved static key.

Version bump to publish the first release under the new PyPI project ownership. No functional changes since 0.2.0.

Hosted-backend support. Point the CLI at any GigaFlow backend. The backend URL resolves as --backend > $GIGAFLOW_BACKEND_URL > saved config backend_url > a built-in default.
API-key authentication. Supply a GigaFlow API key via --api-key, $GIGAFLOW_API_KEY, or the saved config api_key field (resolved in that order). When present it is forwarded on every request as Authorization: Bearer <key>, satisfying the backend's protected Flow compute endpoint.
gigaflow setup now prompts for the backend URL (defaulting to the current resolved value) and an optional API key, persisting both to ~/.gigaflow/config.json.
New api_key config key and _config.get / _config.set helpers.

Resilient HTTP. Requests now use a 30 s timeout and retry idempotent GET/HEAD/OPTIONS calls and connection errors up to three times with exponential backoff. HTTP error responses (4xx/5xx) are never retried so authentication failures surface immediately.
Unreachable-backend and authentication failures now print a short, actionable message instead of a Python traceback.

The CLI remains zero-dependency (Python standard library only).
gigaflow compute continues to forward your OPENAI_API_KEY in the request body for the backend's Flow LLM calls — this is separate from the GigaFlow API key carried in the Authorization header.

Initial release: connect Arize Phoenix traces to GigaFlow, sync, query trace_metrics, compute Flow, and inspect traces in the browser viewer.