The default bug view has changed. See this FAQ.

lots of ValueErrors trying to get fileUrls



Release Engineering
Balrog: Backend
5 months ago
5 months ago


(Reporter: bhearsum, Assigned: bhearsum)


Firefox Tracking Flags

(Not tracked)




(1 attachment)



5 months ago
This have been happening since Sentry was re-enabled, with tracebacks such as:
ValueError: Couldn't find fileUrl
  File "flask/", line 1475, in full_dispatch_request
    rv = self.dispatch_request()
  File "flask/", line 1461, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "flask/", line 84, in view
    return self.dispatch_request(*args, **kwargs)
  File "flask/", line 149, in dispatch_request
    return meth(*args, **kwargs)
  File "auslib/web/views/", line 102, in get
  File "auslib/blobs/", line 152, in getInnerXML
    patches = self._getPatchesXML(localeData, updateQuery, whitelistedDomains, specialForceHosts)
  File "auslib/blobs/", line 532, in _getPatchesXML
    xml = self._getSpecificPatchXML(patchKey, patchType, patch, updateQuery, whitelistedDomains, specialForceHosts)
  File "auslib/blobs/", line 96, in _getSpecificPatchXML
    url = self._getUrl(updateQuery, patchKey, patch, specialForceHosts)
  File "auslib/blobs/", line 607, in _getUrl
    raise ValueError("Couldn't find fileUrl")

...coming from URLs such as

This code was changed at the same time Sentry was enabled in, so that may be a factor.

It's also possible we've got some blobs with bad data in them that need fixing.

Even if this is what's causing the majority of them, I think it's still possible to get into this state by crafting a particular query. We may want to consider not raising an Exception for this scenario, or perhaps raising a different one that doesn't propagate to Sentry.

Comment 1

5 months ago
It looks like this is exclusively coming from beta channel requests that are getting served RCs, eg: like right now when the beta channel is pointed at 50.0 build1. What's happening is that we try to get a fileUrl for a partial in, but can't find one for most old beta versions and end up raising ValueError.

It looks to me like this is the case for all Beta users currently on an RC - they're "from" is set to a release build, but those don't end up in the "beta" section of fileUrls. Prior to bug 1170919, we fell back on the "*" block for this, so it continued to work.

So, 2 things to do here:
1) Fix up the 50.0 blob to stem the bleeding
2) Fix up the submission tools to submit RC releases to the "beta" (& co) blocks.

Comment 2

5 months ago
I'm going to wait until Monday to fix up 50.0 (unless someone wants to do it before me). cc'ing some release folks so they're aware.
I'm not sure what's wrong with 50, I see "beta" in "fileUrls", also LGTM.

Also doesn't make too much sense, 47.0.1 is not a beta version. is the task that sent top level data to balrog. I see the following 2 calls:

15:04:57     INFO - Copy/paste: python /builds/slave/rel-m-rel-fx_upds-000000000000/build/tools/scripts/build-promotion/ --api-root --download-domain --archive-domain --credentials-file /builds/slave/rel-m-rel-fx_upds-000000000000/oauth.txt --product firefox --version 50.0 --build-number 1 --app-version 50.0 --username ffxbld --verbose --channel release --channel release-localtest --channel release-cdntest --rule-to-update firefox-release-cdntest --rule-to-update firefox-release-localtest --platform linux --platform linux64 --platform macosx64 --platform win32 --platform win64 --partial-update 49.0.1build3 --partial-update 49.0.2build2 --requires-mirrors


15:04:59     INFO - Copy/paste: python /builds/slave/rel-m-rel-fx_upds-000000000000/build/tools/scripts/build-promotion/ --api-root --download-domain --archive-domain --credentials-file /builds/slave/rel-m-rel-fx_upds-000000000000/oauth.txt --product firefox --version 50.0 --build-number 1 --app-version 50.0 --username ffxbld --verbose --channel beta --channel beta-localtest --channel beta-cdntest --rule-to-update firefox-beta-cdntest --rule-to-update firefox-beta-localtest --platform linux --platform linux64 --platform macosx64 --platform win32 --platform win64 --partial-update 50.0b11build1

Comment 5

5 months ago
(In reply to Rail Aliiev [:rail] ⌚️ET from comment #3)
> I'm not sure what's wrong with 50, I see "beta" in "fileUrls", also
> x64/en-US/beta/Windows_NT% LGTM.

The problem only exists for users on the beta channel who are currently running an RC build. These sorts of users are expecting to find a partial (because it's listed in the platform+locale section), but cannot find one in the "beta" section of fileUrls since bug 1170919 was landed.

> Also
> msvc-x64/en-US/beta/Windows_NT%
> doesn't make too much sense, 47.0.1 is not a beta version.

Huh, I just assumed that this was something we had shipped to Beta users as an RC. Diving back into rule history, I see that's not the case (we shipped 48.0b1 well before 47.0.1, so we couldn't have done this). Let's forget I pasted this one, and look at these instead:

This is 49.0.2build2 on release-cdntest:

And this is 49.0.2build2 on beta-cdntest:

As you can see, the former gets a partial+complete, the latter gets nothing. Adding the RC entries to the "partials" section of the other explicitly defined channels in the 50.0-build2 blob will fix the latter.

Comment 6

5 months ago
Rail and I talked about this a bit more. He summarized the problem quite nicely: it can only occur when there's a mismatch between the releases listed in the locale section of a blob, and those listed in one of the channels in fileUrls. Eg: in this case, we have releases listed in the locales section that aren't present in the "beta" fileUrls section.

He also noticed that some (possibly all) of these are coming from users on point releases that were never shipped to the beta channel. This leads us to believe that the only people hitting this are those who were on release, and manually switched themselves to beta.

I've gone ahead and updated the Firefox-50.0-build2 blob to include all of the partials in its "beta" fileUrls section. We still need to:
1) Fix Balrog so this doesn't cause a full-blown exception and stop the user from at least getting a complete.
2) Fix the submission tools to always submit all partials to all sections of fileUrls. This will let the users that have somehow gotten into a strange state to receive a partial instead of a complete.

Comment 7

5 months ago
Created attachment 8808249 [details] [review]
don't raise exception if fileUrl for partial can't be found

This adds a unit test that replicates the traceback from Sentry, and "fixes" it by skipping a partial if a fileUrl can't be found. We still raise an exception if we can't find a fileUrl for a complete, because we're likely to end up with no MAR at all in that case.
Assignee: nobody → bhearsum
Attachment #8808249 - Flags: review?(rail)
Attachment #8808249 - Flags: review?(rail) → review+

Comment 8

5 months ago
Commit pushed to master at
bug 1312562: Don't raise exception when fileUrl can't be found for partial update (#171). r=rail


5 months ago
Depends on: 1316112

Comment 9

5 months ago
We haven't seen any more of these since this was deployed to production yesterday. I filed to track updating the submission tools.
Last Resolved: 5 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.