api-tracking

[jirhiker]

Why

This PR addresses the following problem / context:

• Use bullet points here

How

Implementation summary - the following was changed / added / removed:

• Use bullet points here

Notes

Any special considerations, workarounds, or follow-up work to note?

• Use bullet points here

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9da83d5b73

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[Copilot]

Pull request overview

This PR adds API tracking/observability via Apitally, makes Sentry initialization conditional on configuration, and wires the new tracking client ID into the deployment workflows.

Changes:

• Add apitally dependency (and lockfile updates for its transitive deps).
• Initialize Sentry only when SENTRY_DSN is set, and add Apitally middleware when APITALLY_CLIENT_ID is present.
• Update GitHub deployment workflows to set APITALLY_CLIENT_ID and adjust staging MODE.

Reviewed changes

Copilot reviewed 4 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
uv.lock	Locks new dependency graph including apitally, OpenTelemetry, etc.
pyproject.toml	Adds apitally as a project dependency.
main.py	Conditionally initializes Sentry and conditionally adds Apitally middleware.
.github/workflows/CD_staging.yml	Sets MODE to staging and injects APITALLY_CLIENT_ID into App Engine env vars.
.github/workflows/CD_production.yml	Injects APITALLY_CLIENT_ID into App Engine env vars.

[Copilot]

Changing MODE to "staging" will switch the app onto non-production code paths that currently key off settings.mode == "production" (e.g., services/gcs_helper.py uses this to decide whether to load GCS_SERVICE_ACCOUNT_KEY, and core/permissions.py uses it to prevent auth being disabled in production). If staging should still behave like production for these behaviors, consider keeping MODE="production" and passing a separate env var for Apitally’s environment, or updating the production checks to explicitly handle "staging" where appropriate.

Suggested change

	MODE: "staging"
	MODE: "production"
	APITALLY_ENV: "staging"