If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

4% of V4 updates return a 400

RESOLVED DUPLICATE of bug 1332780

Status

()

Toolkit
Safe Browsing
P2
normal
RESOLVED DUPLICATE of bug 1332780
8 months ago
7 months ago

People

(Reporter: francois, Assigned: dimi)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: #sbv4-m5)

(Reporter)

Description

8 months ago
Google reported a spike in update request errors (pver4) starting on January 13, which corresponds to when we enabled V4 updates on Nightly.

According to them, they are receiving protocol buffers that can’t be parsed by their frontend. Chrome had this problem when they weren’t using the right base64 encoding.

This seems to corresponds to about 4% of update requests:

https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2017-01-19&keys=google!other!mozilla!__none__&max_channel_version=nightly%252F53&measure=URLCLASSIFIER_UPDATE_REMOTE_STATUS2&min_channel_version=null&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2016-12-21&table=0&trim=1&use_submission_date=0

Updated

8 months ago
Assignee: nobody → hchang

Comment 1

8 months ago
Padding should be the root cause at the first glance because we [1] use the same padding policy as chromium [2].

[1] https://dxr.mozilla.org/mozilla-central/rev/3cedab21a7e65e6a1c4c2294ecfb5502575a46e3/toolkit/components/url-classifier/nsUrlClassifierUtils.cpp#354
[2] https://chromium.googlesource.com/chromium/src.git/+/3db3676fdfc65bfd15436db3e86f5d5c1bc4536a/components/safe_browsing_db/v4_update_protocol_manager.cc#226

Comment 2

8 months ago
(In reply to Henry Chang [:henry][:hchang] from comment #1)
> Padding should be the root cause at the first glance because we [1] use the
                ^
                NOT  

(sorry for the typo)

> same padding policy as chromium [2].
> 
> [1]
> https://dxr.mozilla.org/mozilla-central/rev/
> 3cedab21a7e65e6a1c4c2294ecfb5502575a46e3/toolkit/components/url-classifier/
> nsUrlClassifierUtils.cpp#354
> [2]
> https://chromium.googlesource.com/chromium/src.git/+/
> 3db3676fdfc65bfd15436db3e86f5d5c1bc4536a/components/safe_browsing_db/
> v4_update_protocol_manager.cc#226
(Reporter)

Comment 3

8 months ago
According to Google, the protobufs we are sending are actually fine.

So, now that bug 1332770 has landed, we should wait a few days and see if we still see the same unusual rate of errors from V4 requests. If we don't, we can close this bug.

Thanks for looking into this Henry. As always, your help is most appreciated.
(Reporter)

Updated

8 months ago
Assignee: hchang → dlee
Status: NEW → ASSIGNED
Priority: P1 → P2
(Assignee)

Updated

7 months ago
Whiteboard: #sbv4-m5
(Assignee)

Comment 4

7 months ago
This issue should have the same root cause as Bug 1332780 that some of the errors may because of connection errors, we could verify this after Bug 1332780 land.

I'll mark this as duplicate as Bug 1332780
Status: ASSIGNED → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1332780
You need to log in before you can comment on or make changes to this bug.