In WP 4.4, comment submission was abstracted so that most of the logic was run in a function that returned a value, rather than inline in wp-comments-post.php. See #34059 for background. This overhaul was incomplete: the process of checking for comment floods and duplicate comments –
wp_allow_comment() and friends – contained direct calls to
wp_die(), making it impossible to use the results of a failed comment check in the context of unit tests, the REST API, or other clients. See #36901.  introduced an optional parameter for
wp_allow_comment() and related functions that lets the caller decide whether to preserve the default behavior (
wp_die()) or, instead, to return
WP_Error objects in the case of failed comment checks.
remove_action( 'check_comment_flood', 'check_comment_flood_db', 10, 3 );
In order to maintain backward compatibility with this usage, while at the same time changing the comment flood check so that it returns a value, we’ve performed a trick:
check_comment_flood_db() is still hooked in the same way, but is now a wrapper for an
add_filter() call that hooks the actual comment flood checking function to the new
The backward compatibility break is as follows. Calling
check_comment_flood_db() directly, in isolation, will no longer do anything (except to register a filter callback). If you need to run WP’s default comment flood check manually, outside the context of
wp_allow_comment(), use the new
wp_check_comment_flood() function. I searched GitHub and the wordpress.org plugin repo and didn’t find a single instance
check_comment_flood_db() being used this way in the wild – it’s hard to imagine a situation where it’d be done, given its previous reliance on
wp_die() – but if you’ve done custom work related to comment floods, it’s worth double-checking your code before 4.7 is released.