Bugfix FXIOS-15847 [Homepage] Serve last known sponsored tiles while revalidating in the background

[devzahirul]

📜 Tickets

Jira ticket
Github issue

💡 Description

This implements the sponsored-shortcuts part of #33899 — "Use stale sponsored shortcuts … while refreshing the cache in the background" — scoped entirely to UnifiedAdsProvider, so it does not change how or when the homepage renders.

Why the shortcuts section stalls on slow networks

• MozAdsClient.requestTileAds is a blocking FFI call, and the ads client's HTTP cache hard-expires entries (default 30 minutes): delete_expired_entries() runs before every lookup, so once the TTL passes the client must go to the network — the previous response is unreadable at that point.
• TopSitesMiddleware.getTopSitesDataAndUpdateState dispatches a single retrievedUpdatedSites action that awaits both getOtherSites() (local, milliseconds) and fetchSponsoredSites(). With an expired ad cache on a slow network, the entire shortcuts section (pinned + history + Google tile — all local data) waits on the sponsored request until the 3-second timeout added in FXIOS-16077.
• When that timeout fires, two more things go wrong: the late result is discarded, so that homepage build shows no sponsored tiles at all; and the blocking call keeps occupying a Swift Concurrency cooperative-pool thread until the request actually finishes, since fetchTiles ran it synchronously on the calling task's thread (the same class of problem as FXIOS-16156 / FXIOS-16307).
• The legacy provider could serve its cached POST response via URLCache within maxCacheAge (30 min) without touching the network. That ability was lost in the Rust ads client migration (FXIOS-14580; legacy path removed with the flag in FXIOS-15992) — the timestamp parameter on fetchTiles has been vestigial since then.

What this PR changes (all inside UnifiedAdsProvider)

1. The blocking requestTileAds call now runs on a dedicated dispatch queue instead of the caller's thread, mirroring DefaultUnifiedAdsCallbackTelemetry (FXIOS-15787) and the merino WC fetcher fix (FXIOS-16156).
2. The provider keeps the last successfully fetched tiles in memory and, while they are at most maxTileStaleness (1 hour) old, completes immediately with them and revalidates in the background. After the first successful fetch of a session, a homepage build never waits on the ad network again. Concurrent revalidations are coalesced.
3. Results arriving after the caller stopped waiting (timeout) are cached, so the next homepage build gets tiles instantly instead of fetching again.

Scope / behavior notes

• Tiles still only change when the homepage naturally rebuilds (initialize / didBecomeActive / topSitesUpdated), so this does not introduce the mid-view content shifting that #33899 ⁃ Improve homepage loading on slow networks when sponsored shortcuts or stories data needs refresh #33899 flags as needing design input.
• Cold start on an expired cache behaves exactly as today (single fetch, 3s cap); the in-memory cache intentionally does not persist.
• The Merino stories half of #33899 ⁃ Improve homepage loading on slow networks when sponsored shortcuts or stories data needs refresh #33899 is untouched and could be a follow-up.
• I saw the Jira note that the Ads team is exploring an async/lazy-load AdsClient. This is deliberately a thin, self-contained layer over the existing client that is trivial to delete when that lands — happy to adjust or park this if you'd rather fold it into that work.

Testing

UnifiedAdsProviderTests covers every branch of the new behavior deterministically (no sleeps, timestamps injected): serving within / at / beyond the staleness bound, revalidation updating the cache, failed revalidation keeping the previous tiles, empty responses being cached, revalidation coalescing while one is in flight, and a late-arriving result being served on the next fetch. Existing tests were updated for the queue-based completion with explicit expectations. SwiftLint passes on the changed files; unit tests run in CI.

🎥 Demos

No visual changes — the shortcuts section simply appears without waiting on the ads request when tiles were fetched within the last hour.

📝 Checklist

• I filled in the ticket numbers and a description of my work
• I updated the PR name to follow our PR naming guidelines
• I ensured unit tests pass and wrote tests for new code
• If working on UI, I checked and implemented accessibility (Dynamic Text and VoiceOver)
• If adding telemetry, I read the data stewardship requirements and will request a data review
• If adding or modifying strings, I read the guidelines and will request a string review from l10n
• If needed, I updated documentation and added comments to complex code

[lmarceau]

Throwing in some thoughts in there 👀 Let me know what you think Roux & Matt!

[lmarceau]

UnifiedAdsProvider is currently using completion handlers since it was introduced at the time as a "let's throw in something quickly to support ads", but it might be worth rethinking it as a whole so we can avoid introducing locking mechanism and support modern concurrency instead.

[lmarceau]

TBH this whole situation looks like we should have this living under the MozAdsClient instead of the Client level UnifiedAdsProvider, what do you think Matt/Roux?

[adudenamedruby]

Yeah, I'm looking into this right now. This whole thing might need a better refactor as it was meant to be temporary.

[devzahirul]

@lmarceau @adudenamedruby Thanks both 🙏 (replying here since I couldn't reply in-thread)

I've reworked UnifiedAdsProvider to drop the NSLock + completion-handler in favour of modern concurrency: it's now an actor with an async fetchTiles, so the in-memory tile cache is protected by actor isolation instead of a lock, and @unchecked Sendable is narrowed to a tiny box around the thread-safe Rust ads client rather than the whole type. The blocking requestTileAds call still runs on the dedicated queue so it never ties up a Swift Concurrency cooperative thread.

I kept it deliberately self-contained and easy to delete or fold into a MozAdsClient-level refactor — so if moving this down to the ads client is the direction you'd rather take, @adudenamedruby, I'm very happy to park this or rework it to fit whatever you land on. The change is pushed.