Skip to main content

Player choice

Automatic Error Reports is on by default when a valid Sentry destination is configured. Turn it off in the overlay’s Interface tab. Turning Akron off in its mod options also stops reports from the next launch, since a disabled Akron does not start reporting. The control is unavailable when no valid destination is configured, and no reports are sent. Reporting does not show a launch notice. Handled errors keep their existing player-facing behavior; automatic reporting does not add an error popup. The preference is stored only in your local mod settings as ErrorReportingEnabled. An existing saved Off choice remains Off. Importing a .akr pack cannot enable it or replace your choice. Turning it off immediately stops new sends and cancels pending requests; a report already sent cannot be recalled. Automatic reports contain the failure phase, exception type, Akron version and Akron method names. Source filenames, line details and debug identifiers are included only when available to the runtime. The player package includes Akron’s portable PDB so Everest can preserve source filenames and line numbers while relinking the assembly. Reports exclude exception messages and data, local directory paths, usernames, machine names, map/save content, other mods’ stack frames, HTTP bodies and URLs, breadcrumbs, and log attachments. The receiving server necessarily sees the network connection’s IP address; the SDK does not add it as a user field. Reporting covers selected failures already caught by Akron: startup helpers, ImGui initialization/rendering, settings saves, deferred actions, StartPos persistence and completion, and unexpected persistent restore failures. Expected cancellation and explicit reconstruction refusals are not reported. Repeated failures from the same phase, exception type and Akron method are reported once per reporting session, with at most 32 reports per session. The client does not install global exception or native crash handlers, record gameplay frames, trace requests, or track sessions. Local Logging and the explicit Send diagnostics flow remain separate. Automatic reporting never uploads those logs or support descriptions. Keep using Send diagnostics when a maintainer needs reproduction details.

Maintainer configuration

The SDK is pinned to Sentry .NET 6.12.0. An absent DSN keeps reporting inert, including in development and CI. Never put an auth token in a build or player setting. Akron owns the SDK’s queue and HTTP client through its public worker/transport extension points. Opt-out and unload cancel pending work and dispose those resources; the standalone SDK client does not create a retained background worker. Sentry rate-limit headers and plain HTTP 429 responses are honored. For a local build, set the public ingest DSN through the MSBuild property AkronSentryDsn. For a local run, AKRON_SENTRY_DSN overrides the compiled value; setting that environment variable to an empty string disables the destination. Only HTTPS DSNs with a public key and numeric project ID are accepted. Reporting follows the player’s local setting, which defaults to On. The maintained Sentry organization is syntaxis-h1 and the mod project is akron. That project discards client IP addresses and derived geolocation, enables default sensitive-data scrubbing, and restricts debug-file downloads to owners. For official releases, configure these values in GitHub’s release-build environment: The release workflow uploads Akron.dll and its portable PDB privately to Sentry, includes embedded source information, and associates release akron@<everest-version> with the exact Git commit. The player ZIP includes only Akron’s portable PDB, which contains code locations and embedded public source; other dependency PDBs and the Sentry CLI remain excluded. Symbol upload is skipped without a DSN; a configured release fails if its symbol-upload credentials are incomplete. Everest rewrites the runtime assembly and its debug identifier. The packaged input PDB lets Everest retain source lines in the rewritten output, which Akron reads at capture time. Private uploads still describe the original build; they do not match Everest’s rewritten debug identifier. An isolated packaged-game run verified filenames and line numbers in a handled settings-save report with the PDB present.

Verification

Run the game-independent suite with a fake HTTP handler; it does not send events to Sentry or need Celeste reference assemblies:
The suite checks disabled reporting, payload redaction through the actual SDK, stable event identity, debug-image index remapping, renderer deduplication, session limits, consent revocation, bounded shutdown, resource disposal across repeated reporting sessions, and server rate limits. The full mod build and settings tests still require the project’s verified Celeste reference archive. Before release, a maintainer should test the visible controls in Celeste/Everest, confirm a controlled handled error in a dedicated Sentry test project, turn reporting off and verify no further requests, and check both normal quit and mod unload. Verify source filenames and line numbers in the captured event after Everest relinks the packaged build. Do not manufacture a gameplay crash to test reporting.