The salt_key field is required but can be set to an empty string, which would use a weak or default encryption key for OAuth tokens stored via django-fernet-encrypted-fields. Similar to the existing IAP validation pattern (lines 297-301 in settings.py), there should be validation that ensures salt_key is non-empty when Linear integration is enabled, since the LinearOAuthToken model uses EncryptedTextField.

When multiple concurrent requests receive a 401 response, they all independently call _request_new_token(), which deletes all existing tokens and creates a new one within transaction.atomic(). While each individual transaction is atomic, the check-then-refresh pattern in _graphql (lines 105-113) is not protected. This could cause one request to delete a valid token that another concurrent request just created, leading to unnecessary token refreshes or intermittent failures under load.

The loop at lines 192-216 executes multiple database queries per issue: _resolve_assignee performs User.objects.filter() and ExternalProfile.objects.update_or_create(), then ActionItem.objects.update_or_create() runs for each issue. While bounded by Linear's API pagination (max ~1250 issues), this could cause performance issues for incidents with many action items.