WordPress.org

Make WordPress Core

Opened 8 months ago

Last modified 6 months ago

#44568 new defect (bug)

Two concurrent post deletes results in invalid return values

Reported by: ajmccluskey Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Posts, Post Types Keywords:
Focuses: rest-api Cc:

Description

Steps to reproduce

Using the REST API:

  • Create a post
  • Run two deletes for created post concurrently:
    1. Force delete (query params: ?force=true)
    2. Delete without forcing (do not specify force query parameter)

Expected

One delete to return 200 OK and a valid return value. The other to return a 404 Not Found or 410 Gone depending on which one was successful.

Result

  1. Force delete returns 200 OK and an empty post object (normally returns a JSON object including keys deleted and previous).
  2. Delete without force returns a post object full of null (see below)
{
    "id": null,
    "date": "",
    "date_gmt": "",
    "guid": {
        "rendered": null,
        "raw": null
    },
    "modified": "",
    "modified_gmt": "",
    "password": null,
    "slug": null,
    "status": null,
    "type": null,
    "link": false,
    "title": {
        "raw": null,
        "rendered": ""
    },
    "content": {
        "raw": null,
        "rendered": "",
        "protected": false
    },
    "excerpt": {
        "raw": null,
        "rendered": "",
        "protected": false
    },
    "author": 0,
    "featured_media": 0,
    "comment_status": null,
    "ping_status": null,
    "sticky": false,
    "template": "",
    "format": "standard",
    "meta": [],
    "categories": [],
    "tags": [],
    "_links": {
        "self": [
            {
                "href": "http:\\/\\/192.168.56.106\\/wp-json\\/wp\\/v2\\/posts\\/"
            }
        ],
        "collection": [
            {
                "href": "http:\\/\\/192.168.56.106\\/wp-json\\/wp\\/v2\\/posts"
            }
        ],
        "about": [
            {
                "href": "http:\\/\\/192.168.56.106\\/wp-json\\/wp\\/v2\\/types\\/post"
            }
        ],
        "wp:attachment": [
            {
                "href": "http:\\/\\/192.168.56.106\\/wp-json\\/wp\\/v2\\/media"
            }
        ],
        "curies": [
            {
                "name": "wp",
                "href": "https:\\/\\/api.w.org\\/{rel}",
                "templated": true
            }
        ]
    }
}

Notes

  • WordPress is latest release version at time of writing (4.9.7)
  • Server OS is Linux (running in a VM with fresh install)
  • Default theme is installed
  • Basic-Auth plugin is the only plugin installed -- required for testing

Change History (3)

#1 follow-up: @soulseekah
8 months ago

Hey there, welcome to Trac! Thanks for your ticket.

WordPress operations are non-atomic. WordPress on the whole is not thread-safe. This means that calling most of the APIs that interact with the database is risky.

If you need to protect your resources from concurrent operations you'll have to perform synchornization (mutexing) yourself.

Rewriting WordPress to be thread-safe means rewriting like 80% of its APIs... a very daunting task. To my knowledge there haven't been any attempts at even trying to include synchronization to API calls. Perhaps it's time...

#2 in reply to: ↑ 1 @ajmccluskey
8 months ago

Hey @soulseekah,

Thanks for the reply, and sorry for the lateness of mine. I didn't realise WordPress wasn't thread-safe. Do you think the WordPress community would be interested in me reporting any scarier concurrency bugs I might find if/when I get back to testing WordPress? I would think it's worthwhile to have a better understanding of the risks/costs of not being thread-safe. If not I'll limit any future reports to those that don't involve concurrency.

Cheers

Replying to soulseekah:

Hey there, welcome to Trac! Thanks for your ticket.

WordPress operations are non-atomic. WordPress on the whole is not thread-safe. This means that calling most of the APIs that interact with the database is risky.

If you need to protect your resources from concurrent operations you'll have to perform synchornization (mutexing) yourself.

Rewriting WordPress to be thread-safe means rewriting like 80% of its APIs... a very daunting task. To my knowledge there haven't been any attempts at even trying to include synchronization to API calls. Perhaps it's time...

#3 @SergeyBiryukov
6 months ago

  • Component changed from General to Posts, Post Types
Note: See TracTickets for help on using tickets.