Escalation on a Factory Reset Boot Loop Nine Days before the Pulse Watch Launch

Okay, everyone, thanks for dropping what you were doing. I'll keep the introductions short because time is the one thing we don't have. I'm Sarah, launch program manager for Pulse Watch 3. As you all know, retail launch is Friday, August 14th, which is nine days from today, and the golden factory build has to be handed to manufacturing on Friday, August 7th. That's two days from now.

Jason, SQE lead for wearables. My team found the issue on Monday night, and Nari has been driving the reproduction since then.

Nari Choi, SQE. I have the reproduction data and the logs ready to share whenever you want them.

Alex from Platform Framework. I own the telephony and connectivity services on the watch, so I suspect this one will end up with me.

Mina, also Framework. I work on boot and recovery, so anything involving crash loops and rescue mode is my area.

Dongwook Kang, Kernel and BSP. I'm here mainly for the modem interface and the early boot timing, in case this turns out to be a driver problem.

Thanks. Here's how I'd like to run this. Ten minutes on the symptom, fifteen on the root cause analysis, then we spend the rest of the time on options and a decision. I need to walk out of this room with a plan I can take to the launch director at 5 p.m.

Here's what we know. On the LTE variant only, if the user activates an eSIM profile and then performs a factory reset, the watch gets stuck in a boot loop. It shows the logo, restarts after about forty seconds, and after five attempts it drops into recovery mode and asks the user to wipe data again. Wiping again doesn't help, because the eSIM profile lives in a separate secure chip and survives the reset.

How often does it happen? Is this every device, or a percentage?

It's not every device. We ran the sequence two hundred times across forty units. It reproduced thirty-one times, so roughly fifteen percent per attempt. Once a device gets into the loop, though, it stays there. We've only been able to recover them with a service tool that clears the eSIM profile, which a normal user doesn't have.

I want to be precise about the scope, because it matters for the decision. The out-of-box experience is not affected. A brand-new watch has no eSIM profile, so the first boot is completely clean. The problem only appears after the user has activated a profile and then resets the watch. Wi-Fi-only models are not affected at all.

That's an important distinction. What share of launch units are LTE?

About thirty-five percent of the initial shipment, and it's concentrated in North America and Korea, where the carriers are promoting it heavily. So it's not a small population.

Alex, Mina, what do the logs tell us about why it loops?

From the boot side, the picture is fairly clear. Each boot, the system server starts, and within thirty seconds, it crashes. The crash is in the eSIM provisioning service, which runs inside the system server. Because the system server crashes repeatedly during boot, the rescue logic concludes the device is unrecoverable and escalates to recovery mode. So the rescue logic is doing exactly what it was designed to do. The real question is why the provisioning service crashes.

And that's where I come in. After a factory reset, the provisioning service finds an existing profile on the secure chip and tries to restore it. To do that, it asks the modem for the profile's network configuration. On a clean boot, the modem is usually ready about twelve seconds after the system server starts. But in the failing cases, the request goes out before the modem has finished initializing, the response comes back empty, and the service dereferences a null object. It's an uncaught exception, and because it's in the system server, it takes the whole process down.

So it's a timing race between the provisioning service and the modem. Why didn't we see it before this week?

I think I can answer that one. Two weeks ago, we merged a boot time optimization in the BSP that starts the system server about six seconds earlier. It was part of the push to get the watch below twenty seconds of boot time. The modem initialization didn't move, so we effectively narrowed the gap between the two. Before that change, the modem was always ready in time.

That matches our data. The first build where Nari can reproduce the loop is the one with the boot time change. We tested two builds before it, and both are clean in a hundred attempts.

I'd add one thing. Even though the boot change exposed it, the underlying bug is the missing null check and the missing retry logic in the provisioning service. It was always fragile. We just got lucky with the timing until now.

Okay. I hear two possible fixes. One, revert the boot time change. Two, fix the provisioning service properly. Let's go through the pros and cons of each, with an eye on Friday's golden build.

The revert is the safest option in terms of code risk. It's a well-understood change, and we've shipped without it for months. The downside is that boot time goes back up to about twenty-six seconds, and marketing has already used the 'under twenty seconds' claim in launch materials.

I'll be honest, that's a conversation I'd rather not have with marketing nine days before launch. But I'd have it if it's the right call. Alex, what about the proper fix?

The proper fix has three parts: a null check on the modem response, a retry with backoff until the modem reports ready, and catching exceptions inside the restore path so a failure there can never take down the system server. I have a draft already. The code is maybe sixty lines. Testing is the bigger question, because this path runs on every boot of every LTE device.

From SQE's perspective, I'm uncomfortable putting a sixty-line change into a code path that runs on every boot, two days before golden. Not because I doubt Alex, but because we wouldn't have time to run the full regression suite. We'd be shipping a change to millions of devices with maybe one day of testing.

I understand the concern, but I'd argue the revert has its own risk. If we revert the boot change, the provisioning bug is still there. It's just hidden again. Any future change that shifts boot timing, or a slower modem firmware update from the carrier, could bring it right back, and next time it might be in the field.

Could we do both, but in different builds? Revert the boot change for the golden factory build, so what goes into the box is proven and safe. Then put the proper provisioning fix, plus the boot optimization, into the day-one update, after it has gone through the full regression suite next week.

I like the shape of that. But let me test it. What happens to a user who buys the watch on launch day, activates an eSIM, and resets it before taking the day-one update?

With the revert in the factory build, that user is fine, because the timing gap is back to what it was. We'd verify that explicitly: I'd want five hundred reset cycles on the golden candidate with zero loops before we sign off.

Five hundred cycles is about twenty hours on forty units if we run them in parallel. If we get the candidate by tomorrow at noon, we'd finish Friday morning, just in time for the handoff.

That's tight, but doable. And for the day-one update, what's the timeline?

If I get my fix reviewed by tomorrow, it can go into the day-one branch on Thursday. SQE runs the full regression from Monday to Wednesday next week. The update would be available on August 14th, the same day as the retail launch, and most users would get it during initial setup.

One caveat from my side. The day-one update would bring the boot optimization back. That means the provisioning fix must be in the same update, never the boot change on its own. I'd like that dependency written into the release checklist, so nobody cherry-picks one without the other.

Good point. I'd also suggest a small hardening change on the boot side: if the system server crashes during boot and the stack trace is in the eSIM restore path, skip the restore and continue booting, instead of escalating to recovery. That way, even if something else goes wrong in that path, the user ends up with a working watch and can re-add the eSIM manually.

I like that as a safety net, but let's not add it to the golden build. For the day-one update, yes, if it's small and well tested.

Now, the marketing issue. With the revert, the factory build boots in about twenty-six seconds. After the day-one update, it's back below twenty. Is the 'under twenty seconds' claim still defensible?

Technically, the claim will be true for the shipping software experience after setup. But I'm not the right person to judge the legal side of that. I'd let marketing and legal decide, with accurate numbers from us.

Agreed. I'll take that one offline with marketing and legal and give them both numbers in writing. The engineering decision shouldn't wait on the wording of a claim.

One more risk to accept explicitly. If the day-one update fails validation next week, we launch with the factory build only, and the boot optimization slips to the first monthly update in September. SQE is fine with that outcome, but I want the launch director to know it's a possibility.

I'll include that in the briefing as plan B. Better to set expectations now than to surprise him next Wednesday.

There's one more angle we haven't covered: the carriers and customer support. Even with this plan, some users will inevitably reset their watches in odd sequences we haven't tested. If one of them gets stuck, what does the support agent tell them?

Right now, the only recovery we've found is the service tool that clears the eSIM profile. Service centers have it, but carrier stores don't. So a user stuck in the loop would have to visit a service center, which isn't a great experience, but at least it's recoverable.

There might be a simpler path. If the paired phone is nearby, the companion app can send a command to disable the eSIM profile before the watch finishes booting. I haven't tried it on a looping device yet, but if it works, support could walk users through it over the phone in two minutes.

That's worth trying today. Nari, could you take two of the looping units and test Alex's idea this afternoon? If it works, it changes the risk profile completely, because a stuck user would no longer need a service visit.

Sure, I can do that right after this meeting. I'll document the exact steps with screenshots, so support can turn them into a script if it works.

Also, we should give the carriers a heads-up. Carrier stores often do a factory reset as their first troubleshooting step, which is exactly the trigger. If they know not to reset LTE watches with an active eSIM until the day-one update is installed, we avoid most of the exposure.

Good thinking. I'll ask the carrier partnership team to send a technical bulletin to store staff before launch, without going into the internal details. Something short and practical: update first, then troubleshoot.

Let me read back the plan. Golden factory build: revert the boot time optimization, nothing else. Dongwook delivers the candidate by noon tomorrow. Nari runs five hundred factory reset cycles with eSIM, and we need zero loops to hand off on Friday. Day-one update: Alex's provisioning fix, Mina's boot hardening, and the boot optimization, always together. Alex gets the fix reviewed by tomorrow, and SQE runs full regression Monday to Wednesday. Is that right?

That's right. I'll send the review request within the hour, and I'll add Mina and Dongwook as reviewers, since the fix touches both the boot sequence and the modem readiness signal. I'd rather have three sets of eyes on it than discover something next week.

And Nari will test the companion app recovery this afternoon, and I'll handle the carrier bulletin and the conversation with marketing and legal. I'll also brief the launch director at five with plan A and plan B.

I'll have the hardening change up for review by tomorrow morning, and I'll keep it small.

And I'll add the dependency rule to the release checklist today, so the boot change can't ship without the provisioning fix.

Great work, everyone. This went from a potential launch blocker to a manageable plan in under an hour. Next checkpoint is tomorrow, Thursday, August 6th, at 6 p.m. Korea time, to review the golden candidate and the first reset results. Same video link. If anything changes before then, message me directly, day or night.

I'll post the cycle count in the channel every four hours, so you'll see the trend before the meeting.

Thanks, Sarah. Let's get this watch out the door.