Note: It's not clear to me whether this repros in a chrome_apk build or not. The suggestions list for my signed-in test user is very close to the default suggestions list.

In (1a), what do you mean by "Observe that the suggestions on the NTP become empty."? Is there no suggestions?

In (2), if you open a new NTP after some time, do you observe different suggestions (more similar to 1a)?

If so, then I would assume that the signed-in request just does not have enough time to finish after FRE and we don't update visible suggestions. 

I've looked into the bug and I can reproduce it (in chrome_apk as well), thanks for the report!

The root cause is a race condition:
 1) you finish FRE, the internal state is still signed-out.
 2) NTP opens which triggers a (signed-out) fetch, the UI shows a spinner
 3) internally, the sign-in finishes, so we ask the backend to delete current suggestions (there are none) and to fetch again (this is ignored because a fetch is in flight)
 4) the (signed-out) fetch finishes, the suggestions appear instead of the spinner

Note that the next fetch will get personalized results.

A proper fix is quite hard. Since the current implementation is in maintenance mode and will be replaced by a new one later in 2018, I'm inclined towards WontFix.

For the record:
 - The proper fix would require cancelling requests in flight.
 - It would be easier to implement that we delay step 3) after the request is finished (swapping steps 3 and 4) but the UI would be very quirky. I think the current bug is better then that.

Tim: do you have an opinion here? 

Should I prioritize this bug or we leave it to be fixed by the Jardin implementation?

TL;DR: If you sign-in during the FRE, the first set of suggestions you see are non-personalized. After the next fetch (maybe the next day), you get personalized suggestions.

Naive question: Would it not be possible to set a flag in the NTP code that says something like signed_in_after_fetch_started_, which then causes the NTP code to drop the result of the signed-out fetch when it returns and kick off a signed-in fetch? All the while the spinner would presumably be going so there wouldn't be any disruption to the user-visible experience. This wouldn't require cancelling requests.

hmm... this is certainly not a nice first run experience. 
Do we have some rough, empiric numbers about the frequency?

The communication between the UI and the request scheduling logic is a bit brittle, so I'm a bit reluctant for changes here.
What's wondering me more: in step 2), couldn't we realize that there's a sign-in in progress and delay or not do that fetch trigger? 
Because once the sign-in finishes, we'd trigger a fetch anyways (step 3)), right?

Tim's excellent question in c#6 made me wonder whether in fact the culprit was actually my CL from Monday: https://chromium-review.googlesource.com/c/chromium/src/+/864151. However, I just verified that it's not: if you sign in during FRE, when the initial fetch occurs, SigninManager::AuthInProgress() is false.

I best empiric number is: on Nexus 6P and GoogleGuest wifi the race condition happens all the time. Not sure how to generalize it.

The proposal of Collin inspired me to a reasonable simple fix attempt. Let me see how it looks.

The proposal of Tim would be even cleaner but I do not think the sign-in service / identity service reveals this info at the moment. Not sure how hard would it be and how robust would it be in the end (w.r.t. such race conditions).

Thanks for the quick input. Given the high likelihood of this problem occurring, I believe we should fix this. Happy to discuss possible workarounds offline.

I have also seen this repro deterministically fwiw.

Re #7 "when the initial fetch occurs, SigninManager::AuthInProgress() is false": does that mean at the time the initial fetch is happening we've signed in, but the fetch itself doesn't know we've signed in?

It seems like delaying the fetch while AuthInProgress is true, coupled with using the up to date credentials once the auth finishes, should fix this? 

IIUC, AuthInProgress is never true on Android, so that can't help here.

It means that at the time the fetch is initiated, we have no signal to find that a sign-in is about to happen. The sign-in process starts only after the fetch is initiated.

Is there some other way to find out that it is worth delaying the fetch when SigninManager::AuthInProgress() is false?

hmmm... this reminds me of a case we had before: https://bugs.chromium.org/p/chromium/issues/detail?id=674433#c20

There, the NTP got displayed during the FRE and when the language was set initially, we thought the language was changed and we cleared the surface.

Are we sure the initial fetch (step (2)) is issued after the FRE is completed or is it possible that this happens while the FRE is still ongoing? If that's the case, then maybe the scheduler can realize somehow that it's still in the FRE?

No no, this case is different. The first fetch is triggered by the NTP being opened.
This event and the event of signing in are only a couple of ms apart.

ok, and to clarify, the NTP is only opened after the FRE is finished. To clarify your last sentence, you're saying that the event of opening the NTP and the sign-in process being finished is only a few ms apart.
Please confirm.

Confirming both:
 1) the NTP is opened after the FRE is finished.
 2) the sign-in process finishes only a few ms after 1)

(please take "a few ms" with a grain of salt; I'd need to run it again to get precise numbers; I perceived it as very quick)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7f933e075d2c44dc0a52df1774a69c91850bf9de

commit 7f933e075d2c44dc0a52df1774a69c91850bf9de
Author: Jan Krcal <jkrcal@chromium.org>
Date: Tue Jan 30 16:38:39 2018

[Remote suggestions] Retry a fetch when suggestions cleared meanwhile

This CL introduces a retry mechanism in RemoteSuggestionsProvider when
suggestions are cleared while a request is in flight.

This change does not violate the previous contract that all fetches are
triggered by the scheduler. From the point of view of the scheduler,
the original fetch and the retry seem as one single fetch.

Bug:  802179 
Change-Id: I6138e16cc68d2a1f4b93576002ce241829255c18
Reviewed-on: https://chromium-review.googlesource.com/873034
Commit-Queue: Jan Krcal <jkrcal@chromium.org>
Reviewed-by: Tim Schumann <tschumann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#532913}
[modify] https://crrev.com/7f933e075d2c44dc0a52df1774a69c91850bf9de/components/ntp_snippets/remote/remote_suggestions_provider_impl.cc
[modify] https://crrev.com/7f933e075d2c44dc0a52df1774a69c91850bf9de/components/ntp_snippets/remote/remote_suggestions_provider_impl.h
[modify] https://crrev.com/7f933e075d2c44dc0a52df1774a69c91850bf9de/components/ntp_snippets/remote/remote_suggestions_provider_impl_unittest.cc