iPad app: Training got stuck at 100%

[microbit-grace]

Occurred in v1.5.1-apps.

Reported by Paul.

The training model did not complete and the progress bar stayed visible once it got to 100% and the app did not move onto the ‘Testing model’ view.

After closing the app and restarting, opening the project the training model worked.

[microbit-grace]

Claude had several suggestions on what might have caused this, but most have been fixed by recent release of v1.5.2-apps:

1. model.fit() never resolves — WebGL/GPU context loss (best fit for the symptoms)

TF.js defaults to the WebGL backend. In an iPad WKWebView the GPU/WebGL context can be lost under memory pressure, on backgrounding, or GPU-process recycling.

Fixed in v1.5.2-apps - Worker uses tf.setBackend("wasm") (ml.worker.ts:43) — CPU, no GPU/WebGL context to lose on backgrounding.

2. An exception after 100%, swallowed by no one

Largely fixed in v1.5.2-apps - Model serialization (modelToArtifacts) and ml4f compile now run inside the worker, wrapped in a .catch that posts an error (ml.worker.ts:107-112). Worker crashes hit onerror → handleFatalError, which resolves the pending request with undefined (ml-worker-client.ts:101-107) → {error:true} → the TrainingError dialog shows instead of hanging.

Not fixed - store.trainModel() still leaves the dialog at TrainingInProgress on success (store.ts:1324-1326) and delegates close+navigate to the caller. The caller handleHelpNext is byte-for-byte identical — still no try/catch around await trainModel(), still gated on if (result) (TrainModelFlowDialogs.tsx:31-36). The progress dialog still has no self-close. So anything that makes the promise hang or reject after the worker returns still strands the 100% dialog.

3. Storage write hangs or silent worker hangs

Not fixed silent worker hangs - If the worker stops responding without firing onerror — exactly what iOS/WKWebView can do when it suspends or kills a backgrounded worker under memory pressure — mlWorker.train() never resolves, the pending map holds a dead promise, and the dialog is stuck at 100% forever. This matches the original report perfectly: transient, iPad-only, cleared by a full restart (which respawns the worker). The move to a worker actually adds this suspension surface.

Not fixed storage write hangs - storageWriteWithErrHandling (store.ts:~2240) catches rejections but not a hang; a stalled SQLite write on iPad still blocks trainModel() from resolving (store.ts:1333), so navigation to Testing never fires.

4. Perceived-stuck tail (not a true bug, but worth ruling out)

Because 100% is shown at the final epoch, the model serialization + SQLite write still run after the bar fills. On a slow iPad with a large project this tail is visible time at "100%" even in the healthy case — so some reports may just be a slow finish rather than a true stall.

Fixed in v1.5.2-apps - Progress is now min(timingProgress, actualProgress) and onProgress(1) fires only after mlWorker.train() resolves (train-model.ts:47, 76-77). 100% now genuinely means the worker returned.