Repository navigation
chore: declare the Sentry DSN as assembly metadata - #2133
Merged
Merged
Conversation
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 #2132 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
The focused implementation preserves existing behavior and includes appropriate metadata validation.
Review effort: Balanced
Findings: None
What changed in this PR
Moves the plugin’s existing Sentry DSN into assembly metadata for host-side routing while preserving current initialization behavior.
Changes:
- Declares the Sentry DSN as assembly metadata.
- Reads the DSN metadata during plugin initialization.
- Adds validation for the generated metadata.
| File | Description |
|---|---|
ItemsPlanning.Pn.csproj |
Declares the Sentry DSN metadata. |
EformItemsPlanningPlugin.cs |
Initializes Sentry using assembly metadata. |
SentryDsnAssemblyMetadataTests.cs |
Verifies metadata presence and format. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #2132
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.<AssemblyMetadata Include="SentryDsn" Value="..." />with the DSN the plugin already uses (moved, not changed).Eform*Plugin.cs: the plugin's ownSentrySdk.Initreads the DSN from that metadata, so the value lives in one place.No behaviour change: same DSN, same options,
Initstays. If the metadata were ever missing the plugin skips itsInitinstead of failing at startup. Nothing reads the metadata until the host change ships; removing the plugin's ownInitis 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 *.csprojreverts 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