Thanks for testing that.
In that case I would not treat the AI plugin as the likely cause. It may just have been a coincidence, or the disable/re-enable cycle may have changed some transient state temporarily.
The most useful next thing to capture is probably the request timing and the pattern of when the warning appears.
For example:
curl -s -o /dev/null \
-w "total=%{time_total}s connect=%{time_connect}s starttransfer=%{time_starttransfer}s\n" \
-X POST "https://your-site.example.com/posts.json" \
-H "Api-Key: YOUR_API_KEY" \
-H "Api-Username: YOUR_USERNAME" \
--data-urlencode "title=API timing test" \
--data-urlencode "raw=Small plain text API test post" \
--data-urlencode "category=1"
If the warning appears again, it would be useful to compare:
- the
time_totalvalue from the client side; - whether it happens only sometimes or on every API post;
- whether it happens after a restart/rebuild, or during normal running;
- whether multiple API requests are being made close together;
- whether the same API call creates the post successfully and only once.
At this point it still sounds like a warning from the API post-create path taking longer than the short mutex window, rather than evidence of a failed post or duplicate-post problem.