Skip to main content
By default, the MobileBoost SDK intercepts failing findElement calls and attempts to self-heal them on the fly. This keeps your tests passing without manual intervention when the UI changes.
Automatic self healing is available in the Java and Python SDKs only. The TypeScript SDK (gpt-driver-node) does not intercept or heal findElement calls. Instead, you opt into recovery per step by passing native Appium code to aiExecute via an appiumHandler: the native block runs first, and the SDK falls back to AI only when it throws. See Deterministic execution.

​
How it works

When a findElement call throws a NoSuchElement exception, the SDK catches it and attempts to resolve the issue by:
  1. Waiting for the element to appear (handles dynamic loading times)
  2. Dismissing unexpected popups or overlays
  3. Scrolling to explore the screen for the element
  4. Inspecting available elements for the same intent (handles changed element IDs)
This allows the SDK to self-heal common flakiness causes:
  • Dynamic loading times
  • Changed element IDs
  • Changed UI layout
  • Changed text or copy
  • Unexpected popups and overlays

​
Reviewing healed steps

All caught exceptions and details about which locator was used to heal the test are available on the MobileBoost dashboard at app.mobileboost.io/gpt-driver/sessions. Each session shows:
  • The original locator that failed
  • The reasoning behind the self-heal attempt
  • Screenshots of the screen at the time of failure

​
Disabling self healing

You can disable self healing for specific commands when you need strict assertions: 
// Disable for a specific findElement call
WebElement el = driver.findElement(By.id("successMessage"), false);
Assert.assertTrue(el.isDisplayed());