Fault-tolerant Unified Execution Engine

The Challenge

The original executor was a monolithic, web-only file with tightly coupled logic, but the platform needed to support mixed web, API, and mobile flows, runtime resource fetching, variable interpolation, logging, auto-healing, and resilient failure handling without creating spaghetti code.

Engineering Approach

• Refactored the old executor into a unified interface that could execute web actions, mobile actions, API calls, and orchestration steps such as loops and waits.
• Implemented independent executors for each action type, including click, hover, double click, file upload, tap, API call, loop, wait, etc., so each step had a single responsibility.
• Used a registry pattern so the orchestrator could resolve the correct executor at runtime based on the current flow step and platform requirement.
• Introduced a shared context that held platform-specific clients such as Playwright, Appium, and libcurl, along with orchestration state like program counters, stack frames, and variables.
• Built shared services for interpolation, resource retrieval, and auto-healing so runtime dependencies could be resolved consistently across platforms.
• Added action listeners that consumed execution events, processed logs through the shared context, and persisted them to the database for execution visibility.
• Handled transient failures explicitly so the engine could record the real failure cause and exit cleanly instead of hiding the error inside a broken execution path.

Impact

• Enabled mixed-platform automation in a single flow, including cases where web, API, and mobile actions needed to share variables and execution state.
• Made the engine more maintainable, fault tolerant, and scalable by isolating platform-specific behavior and keeping the orchestrator free of tangled logic.