gambard@ could you PTAL, maybe assign to someone on the Zine team? 

I think this is related to the way we fetch suggestions.
Assigning to zea@ as Zine owner, cc jkrcal@ as you wrote the implementation of the scheduler.

I think the request simply time-outs. I see no way to extend the timeout in URLFetcher, maybe I am wrong? It seems the only solution would be to retry the fetch.

Currently, we never retry a failed request. This is meant as a server protection (so that traffic does not spike in case of server problems). I can imagine making an exception for time-out but I am not sure if it is a good idea.

This fell off my radar. Sky, I believe you've looked at our retry logic recently?

So far I've been unable to repro. On a M69 local build with GIN-2g. Installing canary now.

For the original instructions, does this repro if you don't perform step #3? Watching the video, it seems the NTP spinner stops when the app is opened in #4. But watching the time in the video, there seems to have been only ~7 seconds between when the fetch should have started and completed. That's not long enough to get hit with timeouts. It isn't clear to me why the fetch failed. 

I feel like #5 is working as intended, we do not currently issue retries for NTP content on failure. Even when Chrome is restarted. Instead we wait a certain amount of time. And there's a button on the screen the user can press to force the fetch. This stance isn't set in stone, we could change it. But I'm hesitant to do something that's risky for the server's health. If we wanted to special case something, I would target scenarios where we don't have any fallback content, which is part of why this is so noticable.

Well, I didn't realize this was reported on iOS. Trying on an iPhone, I think I was able to repro it when I backgrounded. When I didn't background, then the UI actually switched from spinner -> there's no content here -> shows content. Which sounds like we miss some UI timer (and the UI timer is maybe a different length thank on Android?), but then the ultimate showing happens when the request finishes. But if we background the app, some part of this goes wrong.

The UI timeout seems to be 5 seconds, which is inline with what this doc says, https://docs.google.com/document/d/1BCbkOtiiXZ4xU7DfpDp9yfgGi7IQwUA_MQkzUhE_gUE/edit?hl=en# , but I think that's a red herring. It seems that something about backgrounding Chrome (on iOS) is causing the fetch to fail in some way. The fetch has to complete (though not successfully) so that the scheduler can write the fetch attempt time to prefs, so that subsequent fetches will not occur.

Fetches on GIN-2g seem to take 7-10 seconds as a point of reference.