1843175 - TopSitesFeed: Failed to fetch data from Contile server: cacheHeader is null

Status: RESOLVED FIXED

(Firefox :: New Tab Page, defect, P3)

Description

[Rob Wu [:robwu]]

I'm seeing the following warning in the Browser Console at startup:

TopSitesFeed: Failed to fetch data from Contile server: cacheHeader is null

The only potential sources of the error are in https://searchfox.org/mozilla-central/rev/0b021daa5955f0288ef6477fc51be33f7f452f9a/browser/components/newtab/lib/TopSitesFeed.jsm#214-215,219-220

There is a cacheHeader === undefined check before, but that should have been cacheHeader == null (note double-equal: using x == null means: x === null || x === undefined). But cacheHeader === null can also be used, as the only caller of the faulty method passes the value of headers.get(...), which returns a string or null otherwise:
https://searchfox.org/mozilla-central/rev/0b021daa5955f0288ef6477fc51be33f7f452f9a/browser/components/newtab/lib/TopSitesFeed.jsm#340-342

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1833691

:ttran, since you are the author of the regressor, bug 1833691, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 2

[Tif Tran]

will get a patch for this.

Comment 3

[Tif Tran]

Attachment: Bug 1843175 - Handle when cache header is null r=lina,nanj,robwu

Comment 4

[Nan Jiang [:nanj]]

Hi Rob, is this reproducible for you? If so, could you share the STR, please? The backend service (i.e. Contile) should always set the cache header on HTTP 200, otherwise, it'll be a bug with the service. Wanted to see if there is any edge cases. Thanks!

Comment 5

[Rob Wu [:robwu]]

I have witnessed this specific message very often, e.g. during Nightly startup, but also regularly while I have Nightly open. I didn't check for the exact trigger of the issue.

When I use curl to trigger the same request, I also see that the headers are missing. If it matters, I'm sending this request from The Netherlands.

$ curl -v https://contile.services.mozilla.com/v1/tiles -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/116.0'
*   Trying 34.117.237.239:443...
* Connected to contile.services.mozilla.com (34.117.237.239) port 443 (#0)
* ALPN: offers h2
* ALPN: offers http/1.1
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (OUT), TLS handshake, Client hello (1):
* (304) (IN), TLS handshake, Server hello (2):
* (304) (IN), TLS handshake, Unknown (8):
* (304) (IN), TLS handshake, Certificate (11):
* (304) (IN), TLS handshake, CERT verify (15):
* (304) (IN), TLS handshake, Finished (20):
* (304) (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=contile.services.mozilla.com
*  start date: Jun 21 15:09:44 2023 GMT
*  expire date: Sep 19 15:09:43 2023 GMT
*  subjectAltName: host "contile.services.mozilla.com" matched cert's "contile.services.mozilla.com"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* Using HTTP2, server supports multiplexing
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* h2h3 [:method: GET]
* h2h3 [:path: /v1/tiles]
* h2h3 [:scheme: https]
* h2h3 [:authority: contile.services.mozilla.com]
* h2h3 [accept: */*]
* h2h3 [user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/116.0]
* Using Stream ID: 1 (easy handle 0x7fc44600a800)
> GET /v1/tiles HTTP/2
> Host: contile.services.mozilla.com
> accept: */*
> user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/116.0
>
< HTTP/2 200
< server: nginx
< date: Thu, 13 Jul 2023 15:08:30 GMT
< content-type: application/json
< content-length: 12
< access-control-expose-headers: content-type
< vary: Origin, Access-Control-Request-Method, Access-Control-Request-Headers
< access-control-allow-credentials: true
< strict-transport-security: max-age=31536000
< via: 1.1 google
< alt-svc: clear
<
* Connection #0 to host contile.services.mozilla.com left intact
{"tiles":[]}

Comment 6

[Nan Jiang [:nanj]]

Thanks for sharing!

I think Contile didn't set the cache header in this case because it didn't have any content in the response (i.e. "tiles": []). This won't have any user impact, but suppressing the warning is still preferred.

We will make a server-side change in Contile so that it returns HTTP 204 if there is nothing to serve in that region. It used to do that but we made it return HTTP 200 for another bug (which was already fixed a while ago in Firefox).

Comment 7

[Nan Jiang [:nanj]]

Hi :dmeehan, FYI, I've reset the severity from S3 to S4 as this issue won't have any user impact and can be fixed on the server side. The client fix is still nice-to-have but I don't think we need to uplift it.

Comment 8

[Donal Meehan [:dmeehan]]

(In reply to Nan Jiang [:nanj] from comment #7)

Hi :dmeehan, FYI, I've reset the severity from S3 to S4 as this issue won't have any user impact and can be fixed on the server side. The client fix is still nice-to-have but I don't think we need to uplift it.

I'm setting 115 to wontfix again since we won't keep it on the radar for a possible dot release inclusion

Comment 9

[Nan Jiang [:nanj]]

This is also fixed in Contile here. All affected Fx versions should not see this warning any more.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/01c685da09ab
Handle when cache header is null r=nanj

Comment 11

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/01c685da09ab

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:ttran, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox116 to wontfix.

For more information, please visit BugBot documentation.