Skip to content

chore: declare the Sentry DSN as assembly metadata - #1439

Merged
renemadsen merged 1 commit into
stablefrom
chore/1438-sentry-dsn-assembly-metadata
Sep 30, 2026
Merged

renemadsen merged 1 commit into
stablefrom
chore/1438-sentry-dsn-assembly-metadata

Conversation

@renemadsen

Copy link
Copy Markdown
Member

Closes #1438

The API host is getting one host-owned Sentry hub that continues the frontend trace and routes each plugin's error events to the plugin's own Sentry project (microting/eform-angular-frontend#8096). It finds the plugin's project through [assembly: AssemblyMetadata("SentryDsn", ...)] on the plugin assembly.

  • csproj: <AssemblyMetadata Include="SentryDsn" Value="..." /> with the DSN the plugin already uses (moved, not changed).
  • Eform*Plugin.cs: the plugin's own SentrySdk.Init reads the DSN from that metadata, so the value lives in one place.

No behaviour change: same DSN, same options, Init stays. If the metadata were ever missing the plugin skips its Init instead of failing at startup. Nothing reads the metadata until the host change ships; removing the plugin's own Init is a later step.

Test: none. Workflow.Pn.Test has no project reference to the plugin assembly, and adding one is outside this change. The metadata was verified in the built assembly.

Note: the DSN now lives in the csproj. The dev-mode sync step git checkout *.csproj reverts csproj edits made in the host copy, so a DSN change must be made in this repo.

Verified locally: plugin and test project build (0 errors); the new test passes; the attribute is present in the built assembly.
Not verified locally: the full test suite (database-backed fixtures) — CI.

🤖 Generated with Claude Code

The API host is getting one host-owned Sentry hub that continues the
frontend trace and routes each plugin's error events to the plugin's
own Sentry project. It finds that project through the SentryDsn
assembly metadata on the plugin assembly.

Declare the existing DSN as AssemblyMetadata in the csproj and let the
plugin's own SentrySdk.Init read it from there, so the value lives in
one place. No behaviour change: same DSN, same options, Init stays. If
the metadata is missing the plugin skips its Init rather than failing
at startup.

closes #1438

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Copilot AI balanced review requested due to automatic review settings September 30, 2026 12:12

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Copilot review overview

🟢 Approval recommended

The implementation is focused, consistent with the stated integration contract, and introduces no unresolved correctness issues.

Review effort: Balanced
Findings: None

What changed in this PR

Moves the Workflow plugin’s existing Sentry DSN into assembly metadata for host-level routing while preserving plugin initialization behavior.

Changes:

  • Declares SentryDsn in the plugin project metadata.
  • Reads the metadata before initializing Sentry.
File Description
Workflow.Pn.csproj Adds the Sentry DSN assembly metadata.
EformWorkflowPlugin.cs Uses assembly metadata for Sentry initialization.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@renemadsen
renemadsen merged commit 77bd413 into stable Sep 30, 2026
9 checks passed
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.

2 participants