Skip to content

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

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

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

Conversation

@renemadsen

Copy link
Copy Markdown
Member

Closes #1386

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: SentryDsnAssemblyMetadataTests (shape only, no DSN literal, no database); CI runs the whole test project, so it is picked up.

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 #1386

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 satisfies the stated host integration contract and includes focused validation without changing configured Sentry behavior.

Review effort: Balanced
Findings: None

What changed in this PR

Declares the plugin’s existing Sentry DSN as assembly metadata while retaining plugin-owned Sentry initialization.

Changes:

  • Adds SentryDsn assembly metadata.
  • Reads the DSN metadata during Sentry initialization.
  • Tests metadata uniqueness and DSN structure.
File Description
OuterInnerResource.Pn.csproj Declares the Sentry DSN metadata.
EformOuterInnerResourcePlugin.cs Initializes Sentry from assembly metadata.
SentryDsnAssemblyMetadataTests.cs Validates the generated metadata and DSN shape.

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

@renemadsen
renemadsen merged commit dbbd8f0 into stable Sep 30, 2026
7 of 8 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