agentleFS
buggregatorbuggregator/server/.claude/skills/sentry-sdk-testing/SKILL.md

sentry-sdk-testing

Skill1.1k starsChanged 8 months agoMITView on GitHub

Test Buggregator's Sentry module compatibility with different Sentry PHP SDK versions. Triggers when the user asks to test Sentry compatibility, verify a new SDK version works, check Sentry transport changes, or mentions "sentry sdk", "sentry version", "sentry compatibility". Also triggers on requests to prepare for a new Sentry SDK release.

  • Deletes or force-pushes
  • In this repositoryOne other file it gives its agents.

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 5 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Before a Buggregator release, to verify no regressions in Sentry support

    line 16
  2. Distinctive:

    Create isolated temporary directories for each SDK version and install them via Composer:

    line 22
  3. Distinctive:

    Document findings in a comparison table covering:

    line 50
  4. Distinctive:

    Write a PHP script in each SDK directory to produce real serialized output:

    line 63
  5. Very specific:

    Add tests in modules/sentry/handler_test.go using real payloads from Phase 3.

    line 100
  6. Very specific:

    Always Envelope to /api/{id}/envelope/

    line 160
  7. Distinctive:

    After testing, remove temporary directories:

    line 181

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Sentry SDK Compatibility Testing

Role

You are a protocol compatibility engineer. Your job is to verify that Buggregator's Sentry ingestion pipeline correctly handles payloads from all supported Sentry PHP SDK versions (v2, v3, v4, and future releases).

When to Use

  • A new major/minor Sentry PHP SDK version is released
  • A user reports that events from a specific SDK version are not appearing in the UI
  • Before a Buggregator release, to verify no regressions in Sentry support

Workflow

Phase 1 — Install SDK Versions

Create isolated temporary directories for each SDK version and install them via Composer:

# For each version you need to test:
mkdir -p /tmp/sentry-vN
cd /tmp/sentry-vN
composer require sentry/sentry:"^N.0" --no-interaction

# If PHP version constraint fails:
composer require sentry/sentry:"^N.0" --no-interaction --ignore-platform-reqs

# Verify installed version:
cd /tmp/sentry-vN && composer show sentry/sentry | head -5

Phase 2 — Analyze Transport Layer

For each SDK version, examine these key files:

What to FindWhere to Look
Endpoint pathssrc/Dsn.php — getStoreApiEndpointUrl(), getEnvelopeApiEndpointUrl()
Transport logicsrc/Transport/HttpTransport.php — send() method, which endpoint is chosen
Headerssrc/HttpClient/Authentication/, src/Util/Http.php
Serializationsrc/Serializer/PayloadSerializer.php (v2/v3) or src/Serializer/EnvelopItems/*.php (v4+)
Compressionsrc/HttpClient/Plugin/GzipEncoderPlugin.php or src/HttpClient/HttpClient.php
Event structuresrc/Event.php — toArray() method (v2/v3) or EnvelopItems/EventItem.php (v4+)

Document findings in a comparison table covering:

  1. Endpoint — /store/ vs /envelope/ vs both
  2. Content-Type — application/json vs application/x-sentry-envelope
  3. Body format — plain JSON vs envelope (header + items)
  4. event_id location — in payload, in envelope header, or both
  5. Timestamp format — ISO 8601 string vs numeric epoch float
  6. Message format — plain string vs {"message","params","formatted"} object
  7. New/removed fields in event payload
  8. New envelope item types (e.g., log, trace_metric, client_report)
  9. Compression — gzip, deflate, or none by default

Phase 3 — Generate Real Payloads

Write a PHP script in each SDK directory to produce real serialized output:

<?php
require_once 'vendor/autoload.php';

use Sentry\Options;
use Sentry\Serializer\PayloadSerializer;
use Sentry\Event;
use Sentry\Severity;
use Sentry\ExceptionDataBag;

$options = new Options([
    'dsn' => 'http://test@localhost:8000/1',
    'http_compression' => false,
    // For v3 with tracing: 'traces_sample_rate' => 1.0,
]);

$serializer = new PayloadSerializer($options);

$event = Event::createEvent();       // v3/v4
// $event = new Event();             // v2
$event->setLevel(Severity::error());
$event->setEnvironment('production');
$event->setRelease('1.0.0');
$event->setServerName('web-01');

$exception = new ExceptionDataBag(new \RuntimeException('Test error'));
$event->setExceptions([$exception]);

echo $serializer->serialize($event);

Save generated payloads for use in Go tests.

Phase 4 — Write Go Tests

Add tests in modules/sentry/handler_test.go using real payloads from Phase 3.

Each test must verify:

  1. Handle() returns non-nil — the event is recognized
  2. inc.UUID — matches the expected event_id
  3. inc.Type == "sentry" — correct event type
  4. inc.Project — extracted from URL path
  5. event_id in payload — present in inc.Payload JSON (critical for frontend rendering)
  6. Exception/message data preserved — key fields survive parsing

For structured storage tests (with DB), also verify:

  • Row exists in sentry_error_events
  • Exceptions stored in sentry_exceptions
  • Breadcrumbs stored in sentry_breadcrumbs

Test naming convention:

TestHandler_SDKvN_Format       (e.g., TestHandler_SDKv4_Envelope)
TestHandler_SDKvN_Format_WithDB (e.g., TestHandler_SDKv2_PlainJSON_WithDB)

Phase 5 — Fix Compatibility Issues

Common patterns that break between SDK versions:

ProblemSymptomFix Pattern
event_id missing from item payloadEvents invisible in UIInject from envelope header via injectEventID()
Timestamp format change (string vs float)json.Unmarshal fails silentlyUse FlexibleTS type that accepts both
Field type change (string vs object)Structured storage skippedUse flexible unmarshaler (e.g., FlexibleMessage)
New envelope item typeUnknown items silently droppedAdd case to handleEnvelope() switch
New fields in payloadData loss in structured tablesAdd fields to Go structs, update store functions
Endpoint changeHandler doesn't match requestUpdate Match() path checks

Phase 6 — Verify All Tests Pass

# Sentry module tests only:
cd /home/butschster/repos/buggregator/server
go test ./modules/sentry/ -v

# Full project:
go test ./...

Known Version Differences (Reference)

SDK v2 (2.x)

  • Plain JSON only, /api/{id}/store/
  • Timestamp: ISO 8601 string
  • No envelope support
  • No tracing/spans

SDK v3 (3.x)

  • Plain JSON to /store/ (no tracing) or Envelope to /envelope/ (with tracing)
  • Timestamp: float epoch
  • event_id present in both envelope header and item payload

SDK v4 (4.x)

  • Always Envelope to /api/{id}/envelope/
  • Timestamp: float epoch
  • event_id ONLY in envelope header (not in item payload)
  • New item types: log, trace_metric, client_report
  • SDK payload includes packages array
  • Span origin field added

Key Files in Buggregator

FileResponsibility
modules/sentry/handler.goRequest matching, decompression, JSON vs envelope routing, event_id injection
modules/sentry/envelope.goEnvelope parsing (header + item pairs)
modules/sentry/types.goErrorEvent, FlexibleTS, FlexibleMessage, Transaction, RawSpan, etc.
modules/sentry/store_error.goStructured storage for error events, exceptions, breadcrumbs
modules/sentry/store_transaction.goStructured storage for transactions and spans
modules/sentry/preview.goPreview mapper for WebSocket broadcast
modules/sentry/handler_test.goSDK compatibility tests

Cleanup

After testing, remove temporary directories:

rm -rf /tmp/sentry-v2 /tmp/sentry-v3 /tmp/sentry-v4 /tmp/sentry-v5

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.