feat(sentry): tag events with device type, host kernel, and board model - #3021
Merged
Conversation
There was a problem hiding this comment.
Pull request overview
Adds additional host/hardware context to Sentry events so crashes originating inside containers can be segmented by host kernel and board details (useful for diagnosing the armv7 Qt5 webview init crash cohort).
Changes:
- Add
device_type,kernel_release, andkernel_machineSentry tags during Django settings initialization. - Add
board_modeldetection via/proc/device-tree/modeland attach it as a Sentry tag when available. - Add unit tests for the board-model detection helper.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
tests/test_sentry.py |
Adds coverage for the new board-model reader used to populate Sentry tags. |
src/anthias_server/django_project/settings.py |
Initializes new Sentry tags (device type, host kernel info, board model) and introduces get_board_model(). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
- Events are sent from inside containers, so Sentry's stock OS detection never sees the host — the armv7 webview-crash cohort (ANTHIAS-D / ANTHIAS-F) was impossible to segment because nothing on the event said which kernel the device boots - Tag device_type (baked into the image), kernel_release / kernel_machine (containers share the host kernel), and the device-tree board model - Add tests for the board-model reader Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
…idiom Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
vpetersson
force-pushed
the
feat/sentry-device-context
branch
from
June 7, 2026 12:45
a423daa to
b7623ba
Compare
|
5 tasks
vpetersson
added a commit
that referenced
this pull request
Jun 9, 2026
- CalVer (YYYY.0M.MICRO); still June 2026, micro 2 -> 3 - Gives Sentry a real release boundary: every build since 2026.6.2 reported the same base version (only the +git-hash differed), so resolved-in-next-release never stuck and fixed issues kept reopening on the next event. A version bump lets the deployed fixes actually clear from the board. - Ships the crash/noise fixes merged since 2026.6.2: SQLite WAL + busy timeout (#3015), celery migration-gate (#3016) and asset-probe soft limits (#3017), transient-redis/CancelledError Sentry filtering + redis healthcheck (#3018/#3028), GitHub update-check log level (#3019), webview respawn on D-Bus death at setup and mid-play (#3020/#3031), resilient static-file scan (#3026), Wayland-socket wait (#3030), and Sentry release/board triage tags (#3021/#3025) Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>
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.
Issues Fixed
Supports diagnosing Sentry ANTHIAS-D / ANTHIAS-F (armv7 Qt5 webview init crash) — the crash cohort can't currently be segmented by board or kernel.
Description
Events are sent from inside containers, so Sentry's stock OS detection never sees the host. While debugging the webview heap-corruption crash we found the same Qt5/armhf viewer image behaves very differently under a 32-bit vs 64-bit host kernel — and nothing on the events says which one a device boots.
device_type— baked into every image at build time (pi1/pi2/pi3/pi3-64/pi4-64/x86/…)kernel_release/kernel_machine— containers share the host kernel, soplatform.release()/machine()report host valuesboard_model—/proc/device-tree/model(resolves to/sys/firmware/devicetree/base, readable in every container; absent on x86)No PII: board model and kernel version are hardware/software facts, same class as the existing
releasetag.Checklist
🤖 Generated with Claude Code