Overview - Ghost

GhostWorkspace

CI Pipeline Executions
- Filtered
Runs
Demo

Insights

Compare tasks
Analytics

Overview

Ghost

Loading workspace stats

Loading workspace insights...

Statistics interval

7 days30 days

Latest CI Pipeline Executions

Filter

Fuzzy

Sort by

© 2026 - Nx Cloud

Terms of Service Privacy Policy Changelog Status Docs Contact Nx Cloud Pricing Company @NxDevTools

GhostWorkspace

Agents
Replay
VCS
Self-Healing

Average execution time

11m 43s

606 CI pipeline executions

Computation time saved

13d 21h

Cache hit rate

89%

Protect cache integrity with sandboxing

Time to Green

52m 41s

Was 1h 5m, improved by 19%

Succeeded
29682
1f9a08d8 Changed comment cleanup on post deletion to run in the delete transaction ref https://linear.app/ghost/issue/ONC-1925 No foreign key delete rule works for `comments.in_reply_to_id`: `SET NULL` fails mid-cascade (`errno 1452`) for any post with a reply-to-reply comment, and `CASCADE` hits MySQL's 15-level cascade depth limit (`errno 3008`) on long back-and-forth reply chains, which form a linked list through `in_reply_to_id`. The previous approach of migrating the foreign key to `CASCADE` is therefore reverted - the fix is instead to clear `in_reply_to_id` for the post's comments inside the delete transaction (single and bulk destroy), so the existing `post_id` cascade can delete the comments regardless of thread shape
by Michael Ba...
Succeeded
29682
95f34dbf 🐛 Fixed 500 error when deleting posts with threaded comments ref https://linear.app/ghost/issue/ONC-1925 The `comments.in_reply_to_id` foreign key was created with `ON DELETE SET NULL`, while `comments.parent_id` uses `ON DELETE CASCADE`. When a post is deleted, InnoDB cascades into `comments` row by row and the `SET NULL` action issues an `UPDATE` on reply rows whose parent comment is delete-marked in the same cascade. That `UPDATE` re-validates the row's other foreign keys and fails with `ER_NO_REFERENCED_ROW_2` (`errno 1452`), making it impossible to delete any post that has a reply-to-reply comment Switching the action to `CASCADE` makes the post delete cascade deletes-only, which cannot fail this way. Nothing depends on the old `SET NULL` behaviour: it only fires when a comment row is hard-deleted, and the only hard delete in the product is the post delete cascade itself, where every comment is removed regardless. Individual comment deletion is always a soft delete (the `Comment` model overrides `destroy` to set `status='deleted'`), and the UI / serializers handle removed reply targets via that status, not via a nulled foreign key
by Michael Ba...