Application.Storage: foreground and background see different values until reboot (fēnix 9 Pro 47mm, 6.49)

Hi all,

We're seeing stale `Application.Storage` reads between the background service and the foreground of a data field on a fēnix 9 Pro. It looks like the issue in "data is missing after storage setValue call in background", with a few more details.

Setup
- Device: fēnix 9 Pro 47mm (006-B4953-00), firmware 6.49 (DFU-017508)
- Phone: iPhone, Connect IQ app 2.50.1 (1413), Garmin Connect 5.30.1
- App: data field, SDK 9.1.0. A temporal event every 5 min fetches a JSON plan (~7.5 KB) with `makeWebRequest` and saves it as 16 `Storage` values. Then a small index value (`[generation, [keys], 1]`) is written last, as the commit point. The foreground reads the index, then each listed value.
- Control: an epix 2 (006-B3943-00, firmware 26.09) on the same phone, with the same app and the same data, never showed any of this.

What we saw (2026-10-22, UTC)
1. 17:10 to 17:35: on every open of the activity, the foreground read the new index, but at least one of the values it lists came back `null` (read twice in a row). The foreground then wrote a status value to Storage. For the next 25 minutes, the background (new process every 5 min) kept reading the *previous* status value, never the one the foreground wrote. After a reboot, the same stored data loaded fine, and the background immediately read the foreground's status value.
2. Three times (13:07, 17:02, 17:47), a single background run read an *older* version of a value the foreground had written minutes before. The next run read the current value again.

No `StorageFullException` and no crash. The background completed its save each time.

Questions
- Is there a known caching layer between the background and foreground Storage views on this firmware? Is there any call that forces a re-read (other than a reboot)?
- Is `Background.exit(data)` → `onBackgroundData` the recommended way to hand data to a data field, given this? What is its size limit on this device?

Happy to share logs from a sideload build if useful.

Thanks!
  • One thing to remember, is even if you say the background should run every 5 minutes, that's not always the case depending on what else is going on.

    I have always used Background.exit() Early on you couldn't write to storage in the background - only read it.  The max data is about 8k for Background.exit.  It may be larger now, but I kind of doubt it.

  • Thanks Jim. The 8K cap is what stops us using Background.exit for the plan itself (long ultras are ~9 KB parsed), but a small "what I saved" signal via Background.exit is a good idea to detect the stale view. Have you ever seen a foreground keep an old Storage view for many minutes, until a reboot?