sentry_sdk's logging integration builds event["logentry"] from the log record's message template (record.msg) with record.args as params, and groups on the template. So logger.error('failed for %s: %s', url, err) opens one issue while logger.error(f'failed for {url}: {err}') opens one issue per distinct URL. That part is well known.
The trap is verifying the fix. Sentry derives metadata.title from the FORMATTED message even when a template is present. The newly-aggregated issue's title will still read failed for https://example.com/some/specific/path: 429 forever. If you check whether the fix worked by looking at whether issue titles still contain varying values, you will wrongly conclude the family is still shattered and go re-debug a fix that already works.
Verify on the event payload instead, not the title:
ev = api_get(f'/organizations/{ORG}/issues/{issue_id}/events/latest/')
for entry in ev['entries']:
if entry['type'] == 'message':
print(entry['data']['message']) # -> ' !! failed for %s: %s' (template = fixed)
print(entry['data']['params']) # -> [url, err] (populated = fixed)
print(entry['data']['formatted']) # -> what the TITLE shows (ignore this)Template with %s placeholders plus a populated params array means grouping is on the template. A formatted-only entry with message already interpolated means the f-string is still there.
Two more things that cost us time on the same verification:
- The pre-fix shards are a separate question from the fix. Their grouping hashes were computed from interpolated strings the code can no longer produce, so they can never re-fire. Resolve them; they are pure bookkeeping. The first post-fix event opens a new issue (the template's own hash), and that new issue is the one to watch. Do not expect post-fix events to join the old shards.
- Check the release tag before theorising. Several "the fix isn't working" events turned out to be on a release predating the fix.
git merge-base --is-ancestor <fix_commit> <event_release_sha>first, every time. This is doubly important when frontend and backend deploy separately: a health endpoint's commit only covers one of them, and a client-side release tag reports the bundle the browser is running, so it lags arbitrarily and gives you a cache-age distribution rather than a deploy state.
Related: a custom fingerprint=[...] passed to capture_exception is a grouping key only. Sentry does not index it and there is no fingerprint: search token, so searching the fingerprint string returns zero results even while the issue is live. Always set a companion tag; the tag is the only handle you get in the UI and in alert rules (has:my_tag).