DEV Community

HarmonyOS
HarmonyOS

Posted on

Fixing Router Crashes: Calling router.clear() Safely via UIContext.getRouter() in HarmonyOS

Read the original article:Fixing Router Crashes: Calling router.clear() Safely via UIContext.getRouter() in HarmonyOS

Fixing Router Crashes: Calling router.clear() Safely via UIContext.getRouter() in HarmonyOS

Problem Description

The app crashes when router.clear() is invoked inside the callback of router.pushUrl.

Sample:

router.pushUrl(
  { url: 'login/UserNameLoginPage' },
  () => {
    router.clear()
  }
)
Enter fullscreen mode Exit fullscreen mode

Observed log:

Error name: Error
Error message: Internal error. UI execution context not found.
Error code: 100001
Enter fullscreen mode Exit fullscreen mode

Background Knowledge

Global ArkUI APIs (like router) are bound to a concrete UI execution context. At call time, HarmonyOS resolves the current UI instance by tracing the call chain. If you call such APIs from non-UI classes or asynchronous callbacks, the runtime may fail to resolve the current UI context, causing the API to fail. See the @ohos.arkui.UIContext module for context-bound global interfaces.

Troubleshooting Process

  1. Reproduce: Navigate with router.pushUrl(..., callback) and call router.clear() in the callback.
  2. Collect logs: Crash reports show UI execution context not found (100001).
  3. Hypothesis: The callback executes outside the active page’s UI context; the global router cannot bind to a valid UIContext.
  4. Confirm: Moving the call to a place where this.getUIContext() is accessible resolves the error.
  5. Scope check: Same symptom appears when calling other context-bound APIs from non-UI classes or detached async callbacks.

Analysis Conclusion

The crash is caused by invoking a context-bound router API when there is no resolvable UI execution context (async callback / non-UI class). The runtime throws 100001 and the app may crash.

Solution

Method A — Prefer Navigation component as the app’s routing framework.

This avoids direct reliance on global router calls from ambiguous contexts.

Method B — Use UIContext.getRouter() bound to the active page.

Call the router through the current page’s UIContext:

// Inside a UI page/component
this.getUIContext().getRouter().pushUrl(
  { url: 'login/UserNameLoginPage' },
  () => {
    this.getUIContext().getRouter().clear()
  }
)
Enter fullscreen mode Exit fullscreen mode

Non-UI class case — Persist UIContext and use it later

If you must navigate from a non-UI class, persist the UIContext after the page loads and reuse it.

// EntryAbility.ets
onWindowStageCreate(windowStage: window.WindowStage): void {
  windowStage.loadContent('pages/index', (err) => {
    if (err.code) {
      return;
    }
    AppStorage.setOrCreate(
      'UIContext',
      windowStage.getMainWindowSync().getUIContext()
    );
  });
}
// Auth.ets (non-UI class)
export class Auth {
  static gotoLoginPage() {
    const uiContext = AppStorage.get<UIContext>('UIContext');
    if (uiContext) {
      uiContext.getRouter().pushUrl({ url: 'pages/test' });
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Verification Result

  • Reproduced the crash with the original callback approach (error 100001).
  • Verified stability using Method B (getUIContext().getRouter()) and by moving routing into UI components / Navigation framework flows. No crashes observed.

Related Documents or Links

Written by Bunyamin Eymen Alagoz

Top comments (0)