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

12m 28s

683 CI pipeline executions

Computation time saved

15d 57m

Cache hit rate

90%

Protect cache integrity with sandboxing

Time to Green

53m 14s

Was 1h 6m, improved by 20%

Succeeded
30641
778f16cb Stopped unscheduling post jobs on boot ref https://linear.app/ghost/issue/ONC-1983 On boot, post scheduling re-registered every scheduled post by sending the adapter an unschedule followed by a schedule for the same callback URL. With a persistent queue that is a delete-by-URL and a create, and the two are not ordered on the wire. When the create landed first, the delete cancelled both the old job and the new one, and the post never published while Admin kept saying "scheduled". This is what dropped Hyperallergic's post on 1 September, and the same race removes a handful of posts across Ghost(Pro) every week. Post jobs now carry an idempotency key derived from the fire time and the callback URL, so re-registering a job the queue already holds is recognised as the same job and creates nothing. The unschedule on the boot path is therefore redundant, and it is the only thing that can go wrong, so it is gone. Key rotation still unschedules explicitly, because the previous-key URLs differ from the reissued ones and cannot collide with them. Every pending job in the queue must already carry an idempotency key before this ships. A key-less job is invisible to the dedupe, so the first boot after this change would give it a keyed twin and the post would fire twice; the publish callback now tolerates that, but it is still a duplicate delivery worth avoiding for every awake site.
by Sag
S
Succeeded
main
e5c73892 Added progressive payment failure warnings to Admin ref [GVA-988](https://linear.app/ghost/issue/GVA-988) Give publishers advance warning of hosting payment failures and the suspension deadline, with payment and export actions for owners and guidance for staff. Drive warning severity from host configuration behind a flag. Clear warnings after successful payment, preserve legacy behavior when configuration is unavailable, and let open dialogs close before showing the takeover.
by Sag
S
Succeeded
30638
a3f97454 Moved the scheduler idempotency key helper next to the other scheduling helpers ref https://linear.app/ghost/issue/ONC-1983 The automations service was the only consumer of the scheduler's idempotency key support, so the helper that builds the key lived in its folder and hard-coded the `ghost-automations-` prefix. Post scheduling is about to send keys too, and it needs the same recipe with a different namespace. The helper now lives in `adapters/scheduling`, beside `build-signed-job` which is the other half of assembling a job, and takes the namespace as an argument. The automations call site passes `automations`, so the keys it produces are byte-for-byte the same as before and jobs already queued under the old keys still dedupe correctly. This change should not change behaviour.
by Sag
S
Succeeded
30639
27fe2417 Added an idempotency key to scheduled post and page jobs ref https://linear.app/ghost/issue/ONC-1983 Ghost(Pro)'s scheduler keeps its job queue in a database, so every boot rebuild has to replace the job it already holds for each scheduled post: delete by URL, then create. Those two calls are not ordered on the wire. When the create lands first, the delete removes both the old job and the new one, and the post silently never publishes. That is what happened to Hyperallergic on 1 September. The scheduler can already recognise a re-registration if the job carries an idempotency key, which is how the automations poll avoids duplicates. Post and page jobs now send one too, so the boot rebuild can stop deleting in a follow-up once every queued job has a key. The key is a hash of the fire time and the final callback URL, namespaced `post-scheduling`. The URL is the right identity because it already carries the resource ID and a token signed for that fire time under the current signing key: registering the same job again yields the same key, while a reschedule or a key rotation yields a new one. A key based on the post ID alone would dedupe a rescheduled job against the old one that the paired delete is about to remove, which recreates the same race in a new place. This change should not change behaviour: the delete-then-create on boot is untouched, and a persistent queue that already holds a key-less job for a post simply gains a keyed replacement, exactly as it gained a key-less replacement before.
by Sag
S
Succeeded
30641
63161fe1 Stopped unscheduling post jobs on boot ref https://linear.app/ghost/issue/ONC-1983 On boot, post scheduling re-registered every scheduled post by sending the adapter an unschedule followed by a schedule for the same callback URL. With a persistent queue that is a delete-by-URL and a create, and the two are not ordered on the wire. When the create landed first, the delete cancelled both the old job and the new one, and the post never published while Admin kept saying "scheduled". This is what dropped Hyperallergic's post on 1 September, and the same race removes a handful of posts across Ghost(Pro) every week. Post jobs now carry an idempotency key derived from the fire time and the callback URL, so re-registering a job the queue already holds is recognised as the same job and creates nothing. The unschedule on the boot path is therefore redundant, and it is the only thing that can go wrong, so it is gone. Key rotation still unschedules explicitly, because the previous-key URLs differ from the reissued ones and cannot collide with them. Every pending job in the queue must already carry an idempotency key before this ships. A key-less job is invisible to the dedupe, so the first boot after this change would give it a keyed twin and the post would fire twice; the publish callback now tolerates that, but it is still a duplicate delivery worth avoiding for every awake site.
by Sag
S
Failed
30433
d266db33 Cleared inert before the takeover's focus restoration On dismissal the overlay's passive-effect cleanup restored focus while the layout's passive effect had not yet cleared inert from the covered regions — focus() on a still-inert element is a silent no-op, dropping keyboard focus to the body. The inert effect is now a layout effect: React runs all layout effects before any passive-effect cleanups, so the regions are focusable again by the time focus is handed back. Bonus on the way in: inert applies before paint, so there is no frame where the covered page is still reachable. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
by Sag
S
Succeeded
30641
588f4eec Stopped unscheduling post jobs on boot ref https://linear.app/ghost/issue/ONC-1983 On boot, post scheduling re-registered every scheduled post by sending the adapter an unschedule followed by a schedule for the same callback URL. With a persistent queue that is a delete-by-URL and a create, and the two are not ordered on the wire. When the create landed first, the delete cancelled both the old job and the new one, and the post never published while Admin kept saying "scheduled". This is what dropped Hyperallergic's post on 1 September, and the same race removes a handful of posts across Ghost(Pro) every week. Post jobs now carry an idempotency key derived from the fire time and the callback URL, so re-registering a job the queue already holds is recognised as the same job and creates nothing. The unschedule on the boot path is therefore redundant, and it is the only thing that can go wrong, so it is gone. Key rotation still unschedules explicitly, because the previous-key URLs differ from the reissued ones and cannot collide with them. Every pending job in the queue must already carry an idempotency key before this ships. A key-less job is invisible to the dedupe, so the first boot after this change would give it a keyed twin and the post would fire twice; the publish callback now tolerates that, but it is still a duplicate delivery worth avoiding for every awake site.
by Sag
S
Succeeded
30639
63eaefb1 Added an idempotency key to scheduled post and page jobs ref https://linear.app/ghost/issue/ONC-1983 Ghost(Pro)'s scheduler keeps its job queue in a database, so every boot rebuild has to replace the job it already holds for each scheduled post: delete by URL, then create. Those two calls are not ordered on the wire. When the create lands first, the delete removes both the old job and the new one, and the post silently never publishes. That is what happened to Hyperallergic on 1 September. The scheduler can already recognise a re-registration if the job carries an idempotency key, which is how the automations poll avoids duplicates. Post and page jobs now send one too, so the boot rebuild can stop deleting in a follow-up once every queued job has a key. The key is a hash of the fire time and the final callback URL, namespaced `post-scheduling`. The URL is the right identity because it already carries the resource ID and a token signed for that fire time under the current signing key: registering the same job again yields the same key, while a reschedule or a key rotation yields a new one. A key based on the post ID alone would dedupe a rescheduled job against the old one that the paired delete is about to remove, which recreates the same race in a new place. This change should not change behaviour: the delete-then-create on boot is untouched, and a persistent queue that already holds a key-less job for a post simply gains a keyed replacement, exactly as it gained a key-less replacement before.
by Sag
S
Succeeded
30638
cb9dda9d Moved the scheduler idempotency key helper next to the other scheduling helpers ref https://linear.app/ghost/issue/ONC-1983 The automations service was the only consumer of the scheduler's idempotency key support, so the helper that builds the key lived in its folder and hard-coded the `ghost-automations-` prefix. Post scheduling is about to send keys too, and it needs the same recipe with a different namespace. The helper now lives in `adapters/scheduling`, beside `build-signed-job` which is the other half of assembling a job, and takes the namespace as an argument. The automations call site passes `automations`, so the keys it produces are byte-for-byte the same as before and jobs already queued under the old keys still dedupe correctly. This change should not change behaviour.
by Sag
S
Succeeded
30639
773fec98 Added an idempotency key to scheduled post and page jobs ref https://linear.app/ghost/issue/ONC-1983 Ghost(Pro)'s scheduler keeps its job queue in a database, so every boot rebuild has to replace the job it already holds for each scheduled post: delete by URL, then create. Those two calls are not ordered on the wire. When the create lands first, the delete removes both the old job and the new one, and the post silently never publishes. That is what happened to Hyperallergic on 1 September. The scheduler can already recognise a re-registration if the job carries an idempotency key, which is how the automations poll avoids duplicates. Post and page jobs now send one too, so the boot rebuild can stop deleting in a follow-up once every queued job has a key. The key is a hash of the fire time and the final callback URL, namespaced `post-scheduling`. The URL is the right identity because it already carries the resource ID and a token signed for that fire time under the current signing key: registering the same job again yields the same key, while a reschedule or a key rotation yields a new one. A key based on the post ID alone would dedupe a rescheduled job against the old one that the paired delete is about to remove, which recreates the same race in a new place. This change should not change behaviour: the delete-then-create on boot is untouched, and a persistent queue that already holds a key-less job for a post simply gains a keyed replacement, exactly as it gained a key-less replacement before.
by Sag
S
Succeeded
30641
3592012a Stopped unscheduling post jobs on boot ref https://linear.app/ghost/issue/ONC-1983 On boot, post scheduling re-registered every scheduled post by sending the adapter an unschedule followed by a schedule for the same callback URL. With a persistent queue that is a delete-by-URL and a create, and the two are not ordered on the wire. When the create landed first, the delete cancelled both the old job and the new one, and the post never published while Admin kept saying "scheduled". This is what dropped Hyperallergic's post on 1 September, and the same race removes a handful of posts across Ghost(Pro) every week. Post jobs now carry an idempotency key derived from the fire time and the callback URL, so re-registering a job the queue already holds is recognised as the same job and creates nothing. The unschedule on the boot path is therefore redundant, and it is the only thing that can go wrong, so it is gone. Key rotation still unschedules explicitly, because the previous-key URLs differ from the reissued ones and cannot collide with them. Every pending job in the queue must already carry an idempotency key before this ships. A key-less job is invisible to the dedupe, so the first boot after this change would give it a keyed twin and the post would fire twice; the publish callback now tolerates that, but it is still a duplicate delivery worth avoiding for every awake site.
by Sag
S
Succeeded
30638
504fdbbd Moved the scheduler idempotency key helper next to the other scheduling helpers ref https://linear.app/ghost/issue/ONC-1983 The automations service was the only consumer of the scheduler's idempotency key support, so the helper that builds the key lived in its folder and hard-coded the `ghost-automations-` prefix. Post scheduling is about to send keys too, and it needs the same recipe with a different namespace. The helper now lives in `adapters/scheduling`, beside `build-signed-job` which is the other half of assembling a job, and takes the namespace as an argument. The automations call site passes `automations`, so the keys it produces are byte-for-byte the same as before and jobs already queued under the old keys still dedupe correctly. This change should not change behaviour.
by Sag
S
Succeeded
30639
67f7554c Added an idempotency key to scheduled post and page jobs ref https://linear.app/ghost/issue/ONC-1983 Ghost(Pro)'s scheduler keeps its job queue in a database, so every boot rebuild has to replace the job it already holds for each scheduled post: delete by URL, then create. Those two calls are not ordered on the wire. When the create lands first, the delete removes both the old job and the new one, and the post silently never publishes. That is what happened to Hyperallergic on 1 September. The scheduler can already recognise a re-registration if the job carries an idempotency key, which is how the automations poll avoids duplicates. Post and page jobs now send one too, so the boot rebuild can stop deleting in a follow-up once every queued job has a key. The key is a hash of the fire time and the final callback URL, namespaced `post-scheduling`. The URL is the right identity because it already carries the resource ID and a token signed for that fire time under the current signing key: registering the same job again yields the same key, while a reschedule or a key rotation yields a new one. A key based on the post ID alone would dedupe a rescheduled job against the old one that the paired delete is about to remove, which recreates the same race in a new place. This change should not change behaviour: the delete-then-create on boot is untouched, and a persistent queue that already holds a key-less job for a post simply gains a keyed replacement, exactly as it gained a key-less replacement before.
by Sag
S
Succeeded
30638
9e416e57 Moved the scheduler idempotency key helper next to the other scheduling helpers ref https://linear.app/ghost/issue/ONC-1983 The automations service was the only consumer of the scheduler's idempotency key support, so the helper that builds the key lived in its folder and hard-coded the `ghost-automations-` prefix. Post scheduling is about to send keys too, and it needs the same recipe with a different namespace. The helper now lives in `adapters/scheduling`, beside `build-signed-job` which is the other half of assembling a job, and takes the namespace as an argument. The automations call site passes `automations`, so the keys it produces are byte-for-byte the same as before and jobs already queued under the old keys still dedupe correctly. This change should not change behaviour.
by Sag
S
Failed
30641
5d8423ba Stopped unscheduling post jobs on boot ref https://linear.app/ghost/issue/ONC-1983 On boot, post scheduling re-registered every scheduled post by sending the adapter an unschedule followed by a schedule for the same callback URL. With a persistent queue that is a delete-by-URL and a create, and the two are not ordered on the wire. When the create landed first, the delete cancelled both the old job and the new one, and the post never published while Admin kept saying "scheduled". This is what dropped Hyperallergic's post on 1 September, and the same race removes a handful of posts across Ghost(Pro) every week. Post jobs now carry an idempotency key derived from the fire time and the callback URL, so re-registering a job the queue already holds is recognised as the same job and creates nothing. The unschedule on the boot path is therefore redundant, and it is the only thing that can go wrong, so it is gone. Key rotation still unschedules explicitly, because the previous-key URLs differ from the reissued ones and cannot collide with them. Every pending job in the queue must already carry an idempotency key before this ships. A key-less job is invisible to the dedupe, so the first boot after this change would give it a keyed twin and the post would fire twice; the publish callback now tolerates that, but it is still a duplicate delivery worth avoiding for every awake site.
by Sag
S
Succeeded
30639
1d33f74c Added an idempotency key to scheduled post and page jobs ref https://linear.app/ghost/issue/ONC-1983 Ghost(Pro)'s scheduler keeps its job queue in a database, so every boot rebuild has to replace the job it already holds for each scheduled post: delete by URL, then create. Those two calls are not ordered on the wire. When the create lands first, the delete removes both the old job and the new one, and the post silently never publishes. That is what happened to Hyperallergic on 1 September. The scheduler can already recognise a re-registration if the job carries an idempotency key, which is how the automations poll avoids duplicates. Post and page jobs now send one too, so the boot rebuild can stop deleting in a follow-up once every queued job has a key. The key is a hash of the fire time and the final callback URL, namespaced `post-scheduling`. The URL is the right identity because it already carries the resource ID and a token signed for that fire time under the current signing key: registering the same job again yields the same key, while a reschedule or a key rotation yields a new one. A key based on the post ID alone would dedupe a rescheduled job against the old one that the paired delete is about to remove, which recreates the same race in a new place. This change should not change behaviour: the delete-then-create on boot is untouched, and a persistent queue that already holds a key-less job for a post simply gains a keyed replacement, exactly as it gained a key-less replacement before.
by Sag
S
Failed
30640
491a0bce Made the scheduled publish callback safe to receive twice ref https://linear.app/ghost/issue/ONC-1983 The schedules endpoint read the post and then edited it with no transaction and no row lock. A scheduler with a persistent queue can hold two jobs for one post and fire both in the same tick, so the two callbacks overlap: both see the post as scheduled, both flip it to published, and both try to create the newsletter email. Today only the unique index on `emails.post_id` stops a second send, and it does so by failing the second request. In production this pattern shows up a couple of times a day. The read and the edit now run inside one transaction with the row locked for update. The second delivery waits for the first to commit, then finds the post is no longer scheduled and takes the existing no-op path: an empty 2xx the scheduler treats as done. The post is published once, the email is created once, and neither request fails. This is needed before the boot rebuild stops deleting existing jobs, because sites that sleep through that release will briefly hold a key-less job and a keyed twin for each pending post.
by Sag
S
Succeeded
30638
7138fe7d Moved the scheduler idempotency key helper next to the other scheduling helpers ref https://linear.app/ghost/issue/ONC-1983 The automations service was the only consumer of the scheduler's idempotency key support, so the helper that builds the key lived in its folder and hard-coded the `ghost-automations-` prefix. Post scheduling is about to send keys too, and it needs the same recipe with a different namespace. The helper now lives in `adapters/scheduling`, beside `build-signed-job` which is the other half of assembling a job, and takes the namespace as an argument. The automations call site passes `automations`, so the keys it produces are byte-for-byte the same as before and jobs already queued under the old keys still dedupe correctly. This change should not change behaviour.
by Sag
S
Failed
30433
741a70ed Cleared inert before the takeover's focus restoration On dismissal the overlay's passive-effect cleanup restored focus while the layout's passive effect had not yet cleared inert from the covered regions — focus() on a still-inert element is a silent no-op, dropping keyboard focus to the body. The inert effect is now a layout effect: React runs all layout effects before any passive-effect cleanups, so the regions are focusable again by the time focus is handed back. Bonus on the way in: inert applies before paint, so there is no frame where the covered page is still reachable. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
by Sag
S
Succeeded
30433
8aa1e198 Stood the dunning warnings down immediately after a payment Returning from a successful payment still greeted the user with the red banner for several seconds — the warnings only cleared once the billing app's webhook-settled subscription state arrived. The outcome is already known at return time: the billing app's previousPage request only follows a confirmed payment, so the Ember billing service now records a settled-at timestamp alongside the return navigation (the same sessionStorage handshake as the recorded return route), and the dunning state hook reports nothing when a payment settled after the current failure. A later failure carries a newer paymentFailedAt and re-arms the warnings; without storage, the subscription push clears them as before. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
by Sag