Two concurrent post deletes results in invalid return values

[ajmccluskey]

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

[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...

[ajmccluskey]

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...

[TimothyBlynJacobs]

As @soulseekah mentioned, WordPress operations are non-atomic. We discussed this ticket in REST API office hours and couldn't see a good way that the REST API could comprehensively account for this. As such, I'm closing out the ticket.