feat(replays): Query project options directly without going through the project#101605
Conversation
| project = Project.objects.get_from_cache(id=recording.context["project_id"]) | ||
| assert isinstance(project, Project) | ||
| except Project.DoesNotExist as exc: | ||
| logger.warning( | ||
| "Recording segment was received for a project that does not exist.", | ||
| extra={ | ||
| "project_id": recording.context["project_id"], | ||
| "replay_id": recording.context["replay_id"], | ||
| }, | ||
| ) | ||
| raise DropEvent("Could not find project.") from exc |
There was a problem hiding this comment.
Potential bug: Project validation is skipped for replay segments where segment_id != 0, which can cause the occurrence consumer to crash if the project is deleted mid-session.
-
Description: Project existence is only validated for the first replay segment (
segment_id == 0). For subsequent segments, if the associated project is deleted, events like hydration errors or rage clicks are still published to a Kafka topic. The downstream occurrence consumer does not handle this case. When it tries to process these messages, it will attempt to fetch the non-existent project usingProject.objects.get_from_cache, which raises an unhandledProject.DoesNotExistexception. This will cause the consumer to crash, potentially leading to a message backlog and blocking the processing of other valid occurrences. -
Suggested fix: Move the project validation logic, which fetches the
projectobject and checks for its existence, outside and before theif recording.context["segment_id"] == 0:conditional. This ensures that the project is validated for every incoming replay segment before any events are published.
severity: 0.85, confidence: 0.95
Did we get this right? 👍 / 👎 to inform future reviews.
This is a preparatory pull request so we can eventually being caching these queries in a less memory intensive way.