[wp-trac] [WordPress Trac] #17210: Massive duplication of oEmbed postmeta

[WordPress Trac]

#17210: Massive duplication of oEmbed postmeta
--------------------------+------------------------------
 Reporter:  archon810     |       Owner:  Viper007Bond
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Embeds        |     Version:  3.1
 Severity:  normal        |  Resolution:
 Keywords:                |
--------------------------+------------------------------

Comment (by nacin):

 Replying to [comment:18 xknown]:
 > Looking at the WP_Embed code, it seems possible to have duplicate meta
 keys due to concurrency.
 >
 >  - On line http://core.trac.wordpress.org/browser/trunk/wp-
 includes/media.php#L1046, all the oembed meta_keys are deleted after
 saving the post.
 >  - Then, on line http://core.trac.wordpress.org/browser/trunk/wp-
 includes/media.php#L1049, the oembed cache is filled via an ajax call if
 one updates the post (or publishes it). However, at this point the post
 was already inserted in the DB and if it's publicly accessible (i.e. not
 private), it will show up in the front page. Thus, there may be duplicated
 keys if update_post_meta is executed concurrently.
 >
 > One thing to try would be to update the oembed cache before the post
 becomes available on the front page.
 >
 > Not sure if the that makes sense or if it probably means that I have to
 sleep :)

 Makes perfect sense — that's actually why I asked if the author had JS
 disabled, because that would mean the cache wouldn't even be populated at
 all. Definitely possible for there to be a race condition here.

 That said, update/add_metadata() are fairly careful. Pretty crazy traffic
 to cause that kind of flood. Curious if this has been seen on WP.com or if
 the code runs differently there.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/17210#comment:19>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software