From a Sentry issue to a reviewed pull request

Connect the issue source to the right code

Before enabling automatic investigation, check which repository contains the failing application and which release is deployed. A stack trace can refer to a version older than the branch the agent opens. Include release or revision information when it is available, and treat a mismatch as an investigation question.

In Uno, a workspace owner or administrator connects a Sentry Cloud organization from Settings → Integrations → Sentry. The workspace needs an active repository. Each workspace connects to one Sentry organization, and an installation belongs to one workspace. The Sentry integration guide describes connection health and authorization.

Start with repository access the investigation actually needs. The Sentry connection is read-only, while repository access can allow Oncall to change code. Those permissions serve different purposes. Decide who will review the patch and whether a local reproduction needs synthetic fixtures or access to another service.

Know which event starts work

A new grouped issue starts an Oncall session. Another occurrence of that issue, a regression, or a status change does not create another session for the group. This trigger boundary matters when you are testing the integration: a familiar error firing again is not a new-issue test.

Uno retrieves the issue and a representative event, removes known credential fields, and starts the session with the workspace's active repositories. Review what your application sends to Sentry as well. Removing known fields cannot make arbitrary application payloads appropriate to collect or share.

Inspect connection health after setup. If authorization expires, reconnect through the integration page. Disconnecting stops future sessions and preserves those already created. These are the documented integration behaviors; an individual session's messages and outputs show how its investigation progressed.

Turn the error into a checkable failure

Consider an illustrative issue: a results page throws when the search service returns an empty list. The exception points to the first element of the response. Before changing that line, the investigator needs to determine whether an empty list is valid, whether the service request failed, or whether the response shape changed.

A useful investigation note would identify the affected route, the input that causes the failure, the code path, and the expected empty state. It should also say which parts were reproduced. Reading the stack trace and proposing a likely cause are different from running the failing request.

Investigate the empty-results error in the search route.
Check the reported release against the repository revision.
Reproduce with synthetic data if an empty list is a valid response.
Preserve the current API response shape.
Add a regression check and inspect the empty state in the app.
Report any environment access that prevented verification.

This is an example brief you can use to steer an investigation. The expected result is specific enough for a reviewer to reject a patch that simply suppresses the error and leaves a broken page.

Review the cause, patch, and evidence together

Read the proposed cause before the diff. A patch can make the exception disappear while changing the wrong behavior. For the empty-results example, returning a blank screen would hide the crash but still fail the acceptance check that a user can see an empty state and change the query.

Ask the reviewer to compare the new check with the original failure. If the test uses a simplified stub, inspect what that stub assumes about the service response. Confirm that checks ran on the revision under review and that the expected application behavior is visible. Our verification guide covers the handoff in more detail.

Keep failed checks and missing access in the report. An agent may be able to implement a plausible fix while being unable to run an integration test. The reviewer needs that distinction to decide whether to supply a fixture, reproduce the issue elsewhere, or request more work.

Check the release before closing the investigation

Merge and deploy through the process your team already uses. After deployment, verify the affected user flow and check that the expected release is serving. Watch the relevant error and application behavior over a period appropriate to how often the problem occurs.

A quiet error chart immediately after deployment may mean the fix worked, or that no one has exercised the failing path yet. Retain the regression check and the reproduction note so a teammate can assess another occurrence without rebuilding the investigation.

Keep follow-up work separate when it has a different acceptance decision. Improving monitoring, simplifying the service boundary, or adding broader resilience can be sensible tasks. They need their own scope and review, even when the original error revealed the need.