The function uses get_or_create to claim the ExternalLink row, but if the LinearService().create_issue call raises an exception or returns None, the link is deleted. However, between the get_or_create and the delete, a concurrent request could see the placeholder link with empty url and incorrectly assume Linear is already configured. This is a side-effect/concurrency concern in incident creation flow.

Saving the incident with update_fields after a network call to Linear bypasses any optimistic concurrency. If another process modified the incident concurrently (e.g., title updates triggering Linear sync described in the PR), only linear_parent_issue_id is persisted, but the in-memory incident may have stale data for other fields. While update_fields limits the columns written, the incident object used elsewhere in on_incident_created is not refreshed, which could cause downstream hooks to operate on stale data.

Both on_title_changed and on_visibility_changed instantiate a new LinearService() on every invocation. If the constructor performs OAuth token acquisition or other expensive setup, this could create unnecessary overhead and additional API calls per title/visibility change. Consider reusing a module-level service or caching the auth token.