Netflix/Hystrix · error · RuntimeException
Failed executing wrapped Action0
Error message
Failed executing wrapped Action0
What it means
HystrixContextSchedulerAction wraps each Action0 submitted through the Hystrix scheduler so request context can be propagated. Its call() catches any Exception thrown by the wrapped action and rethrows it as this RuntimeException. It is a wrapper around a real failure in user/command code, not a Hystrix defect - always inspect the cause.
Source
Thrown at hystrix-core/src/main/java/com/netflix/hystrix/strategy/concurrency/HystrixContextSchedulerAction.java:71
// set the state of this thread to that of its parent
HystrixRequestContext.setContextOnCurrentThread(parentThreadState);
// execute actual Action0 with the state of the parent
actual.call();
return null;
} finally {
// restore this thread back to its original state
HystrixRequestContext.setContextOnCurrentThread(existingState);
}
}
});
}
@Override
public void call() {
try {
c.call();
} catch (Exception e) {
throw new RuntimeException("Failed executing wrapped Action0", e);
}
}
}
View on GitHub (pinned to 5ce3bc58c3)
Solutions
- Read the nested cause (getCause()) to find the actual failing code and fix it there.
- Ensure command run() translates checked exceptions into HystrixBadRequestException or runtime exceptions deliberately, not accidentally.
- Add onError handling on the observable chain (onErrorResumeNext/doOnError) to handle failures from scheduled actions.
Example fix
// before
public String run() {
return jdbcQuery(sql); // SQLException bubbles out wrapped in RuntimeException
}
// after
public String run() {
try { return jdbcQuery(sql); }
catch (SQLException e) { throw new RuntimeException("query failed", e); }
} Defensive patterns
Strategy: try-catch
Try / catch
try {
action.call();
} catch (RuntimeException e) {
Throwable root = e.getCause() != null ? e.getCause() : e; // unwrap 'Failed executing wrapped Action0'
// handle root cause: business error, bug in run(), etc.
} Prevention
- Always unwrap the cause of this wrapper exception before diagnosing.
- Handle all checked exceptions inside run()/action code explicitly.
When it happens
Trigger: The scheduled action (typically command run()/Observable construction, or user code queued via the Hystrix concurrency strategy's scheduler) throws a checked Exception, which RxJava Action0.call() is not declared to throw, so it is wrapped here.
Common situations: run() throwing a checked exception (SQLException, IOException) that escapes wrapping logic; NPEs inside command code executing on the pool thread; custom code submitted directly to HystrixContextScheduler without its own error handling.
Related errors
- unsupported rx type: {}
- fallback cannot return Observable if command isn't observabl
- fallback cannot return 'void' if command return type is " +
- HystrixCollapser failed while executing.
- Response has already terminated so response can not be set :
AI-assisted analysis of Netflix/Hystrix@5ce3bc58c3 (2026-08-14).
Data as JSON: /api/errors/0c258c838c771cd5.
Report an issue: GitHub.