bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Update checks on getpersonas.com still active.

NEW
Unassigned

Status

addons.mozilla.org Graveyard
Public Pages
P3
normal
5 years ago
2 years ago

People

(Reporter: rfradinho, Unassigned)

Tracking

Details

(Whiteboard: [themes] triaged)

(Reporter)

Description

5 years ago
In bug 860815, we've changed the ETL to look at the new URL used by themes update_check. The old versions are being redirected to this new URL. This was supposed to be a one time redirect, but we still get 67% of about 8855135 daily pings arriving from old versions (these have the src=gp in the URL).

Can you check if the redirect forces the update to the new URL? Or should we continue to have this large number of old versions ?
Group: mozilla-corporation-confidential
(Reporter)

Comment 1

4 years ago
Just looked at the stats and we're getting 41% of daily pings arriving from old versions (these have the src=gp in the URL).

I looked at a particular versiocheck (persona id=94486, addon_id=71640):
https://versioncheck.addons.mozilla.org/en-US/themes/update-check/94486?src=gp
and I see that "updateURL" points to the same URL, not the new one (without the src=gp).

It seems the update to the new URL mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=860815#c5 is not working.
Blocks: 1059966
Priority: -- → P2
The thought behind this is that we only check for updates on the active themes so if people enable an old theme they'd ping getpersonas.com again.  Can you tell us if this is decreasing over time (which would support that hypothesis)?
Flags: needinfo?(rfradinho)
I just re-read comment 1 and bug 860815 comment 5, and it looks like this is a different problem than I expected, and what we're doing does not match the defined behavior.

So the problem is this:

Getpersonas update checks were based on persona IDs. In order to simplify the migration process, the old URLs therefore redirected to a VAMO URL using the persona ID rather than the add-on ID.

The plan was for these to then redirect to a URL using an add-on ID, and also serve updates which point to an update URL using the add-on ID.

What they do instead is explicitly go to pains to preserve the old persona-ID-based URL:

        # If this theme was originally installed from getpersonas.com,
        # we have to use the `<persona_id>?src=gp` version of the `updateURL`.
        if self.from_gp:
            data['updateURL'] += '?src=gp'

which they should not.
Flags: needinfo?(rfradinho)
There seems to be a different problem here, which is that we now use the AMO add-on ID as the persona ID, whereas getpersonas used the persona ID. The update check service ignores responses which do not have the expected ID, so we can't actually update the ID on the client.

Which means that if we want to move to update check URLs using the add-on ID, we're going to need to include a parameter which specifies which ID to return in the update JSON.
(Assignee)

Updated

3 years ago
Product: addons.mozilla.org → addons.mozilla.org Graveyard

Comment 5

2 years ago
Will - is this still a valid issue?
Flags: needinfo?(wclouser)
Priority: P2 → P3
Whiteboard: [themes]
(In reply to :shell escalante from comment #5)
> Will - is this still a valid issue?

I expect so - we never fixed it.  But, we also never figured out why it was happening.  Solving this would require some help and patience from operations.  (I also don't think it's critical since it's been happening for years)
Flags: needinfo?(wclouser)

Updated

2 years ago
Whiteboard: [themes] → [themes] triaged
You need to log in before you can comment on or make changes to this bug.