Skip to content

Conversation

@aaccensi
Copy link
Contributor

Description

Added Sentry UI profiling (automatic instrumentation) and Sentry metrics to count the amount of times data export files are being downloaded.

Type of change

  • Bug fix
  • New feature
  • Enhancement
  • Documentation

Checklist

  • I have tested these changes
  • I have updated documentation as needed
  • I have tagged the relevant people for review

Related Issues

Closes #4633

@aaccensi aaccensi requested a review from noracato January 26, 2026 14:48
Copy link
Member

@noracato noracato left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice job. Just one question about the document policy!

Sentry.init do |config|
# Set release version
config.release = 'stable.01'
config.release = Settings.version
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should start to manually update the string here. Settings.version comes from the docker compose on the (production) server, and will not change when we deploy.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find the idea of manually setting it here for each release too easy to forget. I think it would be best to come up with a rather automatic way, if not fully automatic perhaps a automatic check during one of our CI/CD steps. And that goes for all our apps actually (at least all apps that use Sentry).

For example, I see a couple of routes depending on what's possible:

  • A: We add another entry Settings.release (to config/settings.yml) reading from a new ENV variable if we find a way to keep that ENV updated with the current "git release tag" (not sure if that is possible both in beta and production).
release: <%= ENV.fetch('RELEASE_TAG', '2026-01') %>
  • B: We populate the Settings.release ourselves and we make sure that during a relevant CI/CD step we corroborate that this value is indeed the current "git release tag" (If its easier for the CI/CD check we could even use a dedicated RELEASE file)
release: <%= File.read(File.join(__dir__, 'RELEASE')).strip rescue '2026-01' %>

Isn't something like this reasonable?

before_action :ensure_modern_browser

after_action :teardown_current
after_action :set_document_policy_header
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need this for every action?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need it according to Sentry docs. For every action? I believe so, in this case since all etmodel requests are basically the UI requests we want to profile.

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.

Add Sentry UI profiling and metrics

3 participants