[wp-trac] [WordPress Trac] #51928: Provide plugin/theme update failure data to dot org

[WordPress Trac]

#51928: Provide plugin/theme update failure data to dot org
--------------------------------------+---------------------
 Reporter:  afragen                   |       Owner:  (none)
     Type:  task (blessed)            |      Status:  new
 Priority:  normal                    |   Milestone:  5.6.1
Component:  Upgrade/Install           |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by afragen):

 Replying to [comment:32 dd32]:

 > Reviewing PR 850 above, I have two main questions, neither of which is a
 blocker:
 >
 > https://github.com/WordPress/wordpress-develop/pull/850/files#diff-
 d85d82fa0b14395e2edaaa49f3671189988bc3d7af07e3fccb6b93a00fc99480R982-R999
 >
 >  1. Is it possible to send the Slug of the plugin/theme being updated,
 rather than it's Name?
 >  1. Like above, is it possible to pass through the Slug/Version of
 automatic updates too?
 >
 > I suspect I know the answer here, being that it's hard to retrieve those
 details, but I'm thinking maybe the Automatic updater skin could act as a
 temporary store of what is currently being processed. This could be done
 in a follow up change I guess.
 >
 Unfortunately that data isn't available in the Upgrader object. Depending
 upon the data passed in the WP_Error, it might show the slug by reference
 to the destination folder. I know, not necessarily the same thing.

 > https://github.com/WordPress/wordpress-develop/pull/850/files#diff-
 d85d82fa0b14395e2edaaa49f3671189988bc3d7af07e3fccb6b93a00fc99480R965-R979
 >  1. Due to error_message being translated it's not really storable for
 aggregate stats, Is process & error_code enough of a unique error with
 error_data as context?
 >
 > It can either be kept in the stats blob for easier debugging or removed,
 either is fine, it just won't get stored api-server-side.
 >
 > I'm going to attempt to get some storage running for this
 today/tomorrow, but don't let that block this ticket proceeding. Nothing
 should break by sending this through (at worst, it'll be disregarded as
 junk input, at best, it'll be recorded as successful rather than a
 failure).

 I'm of the opinion that more data is better, but you're the one crunching
 the data so I'll defer to whatever you need/want here. Certainly something
 that can be adjusted in another ticket/later time.

 I have made a small PR to @hellofromTonya's PR
 [https://github.com/WordPress/wordpress-develop/pull/850] to include error
 reporting for `copy_dir()` errors.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/51928#comment:34>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform