Problem: src/selfhost/sentry.ts's resolveSentryMonitorSlug (lines ~156-161) builds Sentry Cron Monitor slugs from a template literal, gittensory-selfhost-${slugPart(environment)}-${SENTRY_MONITORS[name].slug}, and sends that slug to Sentry's Cron Monitor API as the monitor's own identity. The same file also sets Sentry issue-grouping fingerprints carrying the old brand name at line ~461 (scope.setFingerprint(['gittensory-error', eventName])), line ~484 (scope.setFingerprint(['gittensory-review-failure', eventName])), line ~610 (scope.setFingerprint(['gittensory-log', event])), and line ~656 (scope.setFingerprint(['gittensory-sentry-monitor', name])). Separately, .github/workflows/release-selfhost.yml hardcodes SENTRY_ORG: jsonbored and SENTRY_PROJECT: gittensory (also as the fallback default ${{ vars.SENTRY_PROJECT || 'gittensory' }}) at lines ~49-50, ~160-161, ~270, and ~282. None of the 17 known rebrand issues own this, even though D1 (#4767) and the Queue (#4768) already get explicit dual-produce/verify migration treatment for their own third-party-adjacent surfaces. Changing the monitor-slug prefix or any of the fingerprint arrays in place does not rename anything in Sentry — it creates brand-new monitors and splits existing grouped issues into new, ungrouped ones in every self-hoster's own Sentry project, silently losing check-in history and alert continuity.
Area: Infra / Observability
Proposal:
Open question (needs a maintainer decision before starting): Sentry project/monitor slugs are internal identifiers with much lower end-user visibility than a domain name or a check-run name — self-hosters mostly never see them directly. Do we want a full migration here (new Sentry project, transition window, monitor recreation, fingerprint cutover, then retiring the old project) with the attendant monitor/alert continuity cost, the same as D1 and the Queue are getting? Or is gittensory acceptable as a permanent historical artifact in Sentry slugs, left alone indefinitely? This issue's scope depends entirely on that call.
If a full migration is chosen: stand up a new Sentry project under the new name, update SENTRY_ORG/SENTRY_PROJECT in release-selfhost.yml, and update resolveSentryMonitorSlug to emit the new prefix. Run both the old and new monitor slugs in parallel for a transition window so in-flight check-ins and alert routing aren't dropped, confirm alerting fires correctly against the new project, then retire the old monitors and project. All four fingerprint arrays should be updated in the same change so grouping stays consistent going forward, with a note in the migration write-up that historical issues grouped under the old fingerprints will not retroactively merge with new ones.
If the maintainer instead decides to accept gittensory as a permanent Sentry-side artifact, this issue should be closed with that decision recorded, rather than partially migrated.
Deliverables:
- A recorded maintainer decision on whether Sentry project/monitor slugs are in scope for the rebrand.
- If migrating: a new Sentry project receiving self-host error and monitor data, with
release-selfhost.yml's SENTRY_ORG/SENTRY_PROJECT values (including the gittensory fallback default) updated to match.
- If migrating:
resolveSentryMonitorSlug and all four fingerprint arrays updated, with a documented transition window covering the cutover.
Acceptance criteria:
Test scenarios:
- If migrating: trigger a Cron Monitor check-in against the new slug and confirm it registers correctly in the new Sentry project before cutting self-host workflows over.
- If migrating: verify an error event still reaches Sentry and groups sensibly under the new fingerprint arrays after the change.
Resources:
src/selfhost/sentry.ts (resolveSentryMonitorSlug, and the four scope.setFingerprint call sites)..github/workflows/release-selfhost.yml (SENTRY_ORG, SENTRY_PROJECT, and its fallback default).
Boundaries:
- Do not change the monitor-slug prefix or any of the fingerprint arrays without first resolving the open question above — either action unilaterally forks Sentry's monitor and issue history for every self-hoster.
- Leave every reference to the separate gittensor network's own domain/name untouched.
Part of #4761.
Problem:
src/selfhost/sentry.ts'sresolveSentryMonitorSlug(lines ~156-161) builds Sentry Cron Monitor slugs from a template literal,gittensory-selfhost-${slugPart(environment)}-${SENTRY_MONITORS[name].slug}, and sends that slug to Sentry's Cron Monitor API as the monitor's own identity. The same file also sets Sentry issue-grouping fingerprints carrying the old brand name at line ~461 (scope.setFingerprint(['gittensory-error', eventName])), line ~484 (scope.setFingerprint(['gittensory-review-failure', eventName])), line ~610 (scope.setFingerprint(['gittensory-log', event])), and line ~656 (scope.setFingerprint(['gittensory-sentry-monitor', name])). Separately,.github/workflows/release-selfhost.ymlhardcodesSENTRY_ORG: jsonboredandSENTRY_PROJECT: gittensory(also as the fallback default${{ vars.SENTRY_PROJECT || 'gittensory' }}) at lines ~49-50, ~160-161, ~270, and ~282. None of the 17 known rebrand issues own this, even though D1 (#4767) and the Queue (#4768) already get explicit dual-produce/verify migration treatment for their own third-party-adjacent surfaces. Changing the monitor-slug prefix or any of the fingerprint arrays in place does not rename anything in Sentry — it creates brand-new monitors and splits existing grouped issues into new, ungrouped ones in every self-hoster's own Sentry project, silently losing check-in history and alert continuity.Area: Infra / Observability
Proposal:
Open question (needs a maintainer decision before starting): Sentry project/monitor slugs are internal identifiers with much lower end-user visibility than a domain name or a check-run name — self-hosters mostly never see them directly. Do we want a full migration here (new Sentry project, transition window, monitor recreation, fingerprint cutover, then retiring the old project) with the attendant monitor/alert continuity cost, the same as D1 and the Queue are getting? Or is
gittensoryacceptable as a permanent historical artifact in Sentry slugs, left alone indefinitely? This issue's scope depends entirely on that call.If a full migration is chosen: stand up a new Sentry project under the new name, update
SENTRY_ORG/SENTRY_PROJECTinrelease-selfhost.yml, and updateresolveSentryMonitorSlugto emit the new prefix. Run both the old and new monitor slugs in parallel for a transition window so in-flight check-ins and alert routing aren't dropped, confirm alerting fires correctly against the new project, then retire the old monitors and project. All four fingerprint arrays should be updated in the same change so grouping stays consistent going forward, with a note in the migration write-up that historical issues grouped under the old fingerprints will not retroactively merge with new ones.If the maintainer instead decides to accept
gittensoryas a permanent Sentry-side artifact, this issue should be closed with that decision recorded, rather than partially migrated.Deliverables:
release-selfhost.yml'sSENTRY_ORG/SENTRY_PROJECTvalues (including thegittensoryfallback default) updated to match.resolveSentryMonitorSlugand all four fingerprint arrays updated, with a documented transition window covering the cutover.Acceptance criteria:
Test scenarios:
Resources:
src/selfhost/sentry.ts(resolveSentryMonitorSlug, and the fourscope.setFingerprintcall sites)..github/workflows/release-selfhost.yml(SENTRY_ORG,SENTRY_PROJECT, and its fallback default).Boundaries:
Part of #4761.