Repository navigation
feat(tasks): summarize endpoint - #56959
Conversation
Prompt To Fix All With AIThis is a comment left during a code review.
Path: products/tasks/backend/serializers.py
Line: 780-784
Comment:
**`latest_run` silently returns `None` when status is falsy**
`_latest_run_status` is checked against `None`, but Django's `Subquery` can return any falsy value (e.g. an empty string `""`) for a non-null DB column if data is inconsistent. More importantly, `TaskRun.Status` has the value `"not_started"` which is always truthy, but the check `if status is None` is specifically testing for `None` (no-run case). This logic is correct *today*, but it's fragile: if `status` were ever an empty string or `0`, a task with a real latest run would be reported as having none.
A safer and more explicit check would distinguish "no run found" from "run found with some status":
```python
def get_latest_run(self, obj):
status = getattr(obj, "_latest_run_status", None)
environment = getattr(obj, "_latest_run_environment", None)
if status is None and environment is None:
return None
return {"status": status, "environment": environment}
```
This still relies on the subquery returning `None` only when no run exists, but is more robust to future additions of nullable status values.
How can I resolve this? If you propose a fix, please make it concise.
---
This is a comment left during a code review.
Path: products/tasks/backend/api.py
Line: 255-271
Comment:
**Two correlated subqueries for the same row**
`_latest_run_status` and `_latest_run_environment` are two independent correlated subqueries that each re-evaluate the `ORDER BY -created_at, -id LIMIT 1` logic on `TaskRun`. On most databases this generates two identical index scans per task row. If the `TaskRun` table grows large, this doubles the per-row subquery cost. Consider using a single subquery that returns a JSON object (or use `Window` + `Subquery` with a single value), or accept the current approach if perf is acceptable at your task/run cardinalities.
How can I resolve this? If you propose a fix, please make it concise.Reviews (1): Last reviewed commit: "better less bad endpoint" | Re-trigger Greptile |
|
⏭️ Skipped snapshot commit because branch advanced to The new commit will trigger its own snapshot update workflow. If you expected this workflow to succeed: This can happen due to concurrent commits. To get a fresh workflow run, either:
|
Query snapshots: Backend query snapshots updatedChanges: 1 snapshots (1 modified, 0 added, 0 deleted) What this means:
Next steps:
|
Generated-By: PostHog Code Task-Id: ef5b8a8f-92da-473e-bd2a-e71dd9ffe0d0
|
Size Change: 0 B Total Size: 141 MB ℹ️ View Unchanged
|
|
⏭️ Skipped snapshot commit because branch advanced to The new commit will trigger its own snapshot update workflow. If you expected this workflow to succeed: This can happen due to concurrent commits. To get a fresh workflow run, either:
|
Generated-By: PostHog Code Task-Id: 77ffbb16-3a1a-482a-9af0-8c8c563fb8d8
Problem
Our other task retrieval endpoint is pretty slow, we need a specialised endpoint for getting tasks for the sidebar in PostHog Code. See PostHog/code#1945
Changes
How did you test this code?
👉 Stay up-to-date with PostHog coding conventions for a smoother review.
Publish to changelog?
Docs update
🤖 Agent context