Skip to content

Make Sentry setup visible: startup log, release from the commit, /health version - #160

Merged
jeffmaki merged 3 commits into
developfrom
sentry-startup-log
Oct 28, 2026
Merged

jeffmaki merged 3 commits into
developfrom
sentry-startup-log

Conversation

@jeffmaki

Copy link
Copy Markdown
Contributor

Sentry wasn't receiving any backend events. The code was fine, but the App Services never set SENTRY_DSN, and without a DSN the SDK silently sends nothing. Prod now has SENTRY_DSN and ENV, set by hand. This PR makes a missing setting visible and fills in the release.

Startup log line. Sentry setup moves into init_sentry() in api/main.py, with the same settings as before; logging is now configured just before it. At startup it logs either:

  • WARNING … SENTRY_DSN is not set, so errors are not reported to Sentry, or
  • INFO … Reporting errors to Sentry: environment='production', release='<sha>'.

Release from the commit. Every event reported release unknown, because nothing set CODE_VERSION.

  • The Dockerfile now takes a CODE_VERSION build argument and sets it as an environment variable, defaulting to unknown. It's declared after the dependency install, so a new commit doesn't invalidate the cached layers.
  • push-docker-image.yml (the deploy workflow, also run by trigger-deploy-on-merge.yml) and docker-image.yml pass CODE_VERSION=${{ github.sha }}. That's the same SHA the deploy workflow uses as an image tag, so a Sentry release maps to the image you'd roll back to.
  • Don't set CODE_VERSION as an App Service setting: it would override the image's value.

/health reports the running commit. It now returns {"status": "ok", "version": "<CODE_VERSION>"}, so you can confirm which commit is deployed with curl. status is unchanged, and probes only check the status code. The repo is public, so the SHA reveals nothing new.

Still to do outside this PR: add SENTRY_DSN and ENV (stage, dev) on ws-backend-stage and ws-backend-dev. Prod already has them.

Testing:

  • New unit tests cover the startup warning and info line, with the Sentry SDK stubbed out.
  • Two /health tests cover version with and without CODE_VERSION.
  • A local Docker build confirmed the build arg reaches the container (and defaults to unknown without it).
  • Run against a local fake Sentry server, the app reported an unhandled route exception, a logger.error call and a capture_message call once a DSN was set.
  • ./scripts/ci.sh passes.

🤖 Generated with Claude Code

jeffmaki and others added 3 commits October 28, 2026 16:46
Without SENTRY_DSN the Sentry SDK silently sends nothing; the App
Services ran that way and nobody could tell. Log a warning when it's
missing, and the environment and release when it's set.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sentry's release (and the startup log line) read CODE_VERSION, which
nothing set, so every event reported release "unknown". The image
workflows now pass the commit SHA as a build arg; the Dockerfile sets it
last so a new commit doesn't invalidate the dependency layers.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
/health now returns {"status": "ok", "version": <CODE_VERSION>}, so a
deploy can be confirmed from outside. "unknown" for an image built
without the build arg.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Oct 28, 2026

Copy link
Copy Markdown

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

Run configuration
  • Source mode: Auto
  • Repository: Unavailable
  • Branch: Unavailable
  • File: No configuration file from this repository applied
  • Commit: Unavailable
  • Layers: Organization UI
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: a5f5f6bc-ba9d-4f40-9956-220c23164964

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@jeffmaki
jeffmaki merged commit 43df931 into develop Oct 28, 2026
2 checks passed
This was referenced Oct 28, 2026
jeffmaki added a commit that referenced this pull request Oct 30, 2026
* Update push-docker-image.yml

Pushes the workspaces-backend to the app service on push

* Update push-docker-image.yml

added other step for building the environment

* Update push-docker-image.yml

v3 deployment

* Update push-docker-image.yml

* Update push-docker-image.yml

name check

* Add GET /workspaces/{id}/fixmes for the review queue (#154)

Lists the workspace's current elements with a non-empty fixme tag (the key in
any case, e.g. FIXME), newest first, each with its note, version, changeset,
timestamp, tags and a location: a node's own, or the middle of a way's nodes
(none for a relation). The OSM API can't search by tag, so, like the bbox and
adiff endpoints, this reads the workspace's tables directly. Anyone who can
open the workspace can call it.

Checked against a real Postgres with the OSM current_* tables: nodes, ways
and relations are found, empty notes and deleted elements aren't.

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

* Implement workspace creation permissions based on TDEI roles (#147)

* Implement workspace creation permissions based on TDEI roles and update tests

* Implement TDEI dataset fetching and workspace creation validation based on dataset status and project group

* Implement workspace creation permission checks and related API endpoint

* Rename TDEI client variable for consistency in security and test files

* Add TDEI API backend URL and enhance dataset handling in workspace creation

- Introduced TDEI_API_BACKEND_URL in .env.example and docker-compose.local.yml for environment configuration.
- Added same_uuid function to compare UUIDs in a case-insensitive manner.
- Enhanced TdeiDataset class to include data_type and added matches_type method for workspace type validation.
- Updated fetch_tdei_dataset to handle dataset type and improved error handling for TDEI API responses.
- Modified WorkspaceRepository to enforce dataset type restrictions during workspace creation.
- Expanded integration and unit tests to cover new dataset type validations and TDEI API error scenarios.

* Document the workspace creation rule in CLAUDE.md

Who may create a workspace (POC, or the data generator of the matching
type), the extra checks when creating from a TDEI dataset, and that
tdei-admin gets no extra rights.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Normalize TDEI project group role names

Trim and lowercase the roles TDEI returns so "POC" or " poc " grant the
same rights as "poc", as the frontend's hasCreationRole already does.
Roles the backend doesn't model (e.g. tdei-admin) are dropped; they
granted nothing.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Require TDEI_API_BACKEND_URL with no default

A dev default would quietly send prod tokens to api-dev.tdei.us when a
deployment doesn't set it. Fail at startup instead, including for the
empty string docker-compose passes when the variable is unset.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

---------

Co-authored-by: Jeff Maki <hello@jeffmaki.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

* Make GET /workspaces/mine smaller and cheaper (#158)

- Apply gig_only, which the ScoutRoute apps already send: only OSW
  workspaces open to external apps. lat, lon and radius stay ignored on
  purpose.
- Don't load the geometry column or join in the long-form quest and
  imagery definitions; the list response sends none of them.
- Gzip responses from this service's own API (/api/v1/) for clients that
  accept it. Proxied OSM traffic is left as received.

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

* Make Sentry setup visible: startup log, release from the commit, /health version (#160)

* Say at startup whether errors reach Sentry

Without SENTRY_DSN the Sentry SDK silently sends nothing; the App
Services ran that way and nobody could tell. Log a warning when it's
missing, and the environment and release when it's set.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Bake the commit into the image as CODE_VERSION

Sentry's release (and the startup log line) read CODE_VERSION, which
nothing set, so every event reported release "unknown". The image
workflows now pass the commit SHA as a build arg; the Dockerfile sets it
last so a new commit doesn't invalidate the dependency layers.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Report the running commit from /health

/health now returns {"status": "ok", "version": <CODE_VERSION>}, so a
deploy can be confirmed from outside. "unknown" for an image built
without the build arg.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>

---------

Co-authored-by: Naresh Kumar D <susrisha@gmail.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Rajesh Kantipudi <44539669+iamrajeshk@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant