Releases

A release is the version string you attach to a deployment. Every error, transaction and product event carries it, which is what turns "this started recently" into "this started in 2.8.4".

Setting the release

The release is set once, in SDK configuration, and should come from your build rather than be typed by hand — a release that lags behind the deployment is worse than no release at all.

builder.Services.AddErrorDock(options =>
{
    options.ApiKey = builder.Configuration["ErrorDock:ApiKey"];
    options.Endpoint = "https://api.errordock.com";
    options.Environment = builder.Environment.EnvironmentName;
    options.Release = typeof(Program).Assembly.GetName().Version?.ToString();
});

import { init } from "@errordock/browser";

init({
  apiKey: "ed_pub_...",
  endpoint: "https://api.errordock.com",
  environment: "production",
  release: "2.8.4",
});

Any stable string works. A semantic version, a build number or a commit SHA are all fine; what matters is that the same string identifies the same deployed artefact everywhere it appears.

Introduced in, resolved in

Every issue records the first release it appeared in. When a fix ships and the issue stops occurring, it records the release that resolved it. "Introduced in v2.8.4" turns a debugging session into a diff.

This is also why the release should match something you can look up. A release string of latest tells you an issue is new; a release string of 2.8.4 tells you which commits to read.

Regression detection

If a resolved issue reappears in a later release, ErrorDock reopens it and marks it a regression rather than creating a new issue.

Without that, a fix that did not hold looks like a brand-new bug and gets triaged from scratch — by someone who may not know it was ever fixed. The regression flag carries that history forward.

Release health

Each release carries its own numbers, compared against the release before it, so a bad deployment shows up as a step change rather than as a slow drift.

Source maps

Source maps are uploaded per release, so a stack trace resolves against the exact build it came from. ErrorDock accepts JavaScript source maps and composed Hermes source maps for React Native:

curl -X POST "https://api.errordock.com/v1/artifacts?release=2.8.4&name=main.a83f2.js.map" \
  -H "Authorization: Bearer $ERRORDOCK_KEY" \
  --data-binary @dist/main.a83f2.js.map

The key is a server key (ed_live_) with the artifacts:write scope, and a map can be up to 60 MB. During the beta, source-map upload is enabled per organisation.

If two deployments share a release string, the second upload overwrites the first and traces from the earlier build stop resolving. One release string per artefact.

.NET stack traces are not symbolicated on the server: publish or embed portable PDBs, and the runtime puts file and line into the trace before it is sent. dSYM files and ProGuard or R8 mappings are not supported.

Related

• Capturing errors
• Transactions
• Product Health: feature health and priorities