GeezerVison

Description

capture_checkin returned a check-in id even when the check-in wasn't sent, because it ignored the return value of capture_event. That happens when there is no active client, or when before_send drops the event. A caller that hands the id to another process (as in the issue: the scheduler opens the check-in, the worker closes it, and opens its own only when no id arrives) can't tell that the check-in never reached Sentry.

It now returns None in that case, the same way capture_event does. monitor and the Celery Beat integration pass the returned id into the closing capture_checkin call, which generates a new id when it gets None, so they behave as before. The return type becomes Optional[str], so type-checked code that uses the result as a str will now get a mypy error until it handles None. test_capture_checkin_sdk_not_initialized expected the passed-in id back when the SDK isn't initialized and now expects None.

The alternative was keeping the str return type and adding a separate way to ask whether the check-in went out, but None matches capture_event and needs no new API.

Issues

• resolves: capture_checkin returns a check-in id even when the check-in was not sent #7845
• resolves: PY-2924