Seems like a nice method to add, though maybe not so helpful in our codebase specifically since we would probably still generally pick the former for better performance. Want to make sure no one picks up this issue and rewrites all the current usage at the same time as adding the method :)

since we would probably still generally pick the former for better performance

Good point, we create an additional Runnable object to use ctx.run().

Want to make sure no one picks up this issue and rewrites all the current usage at the same time as adding the method

I think we don't need to change the current usage in our code base. Let's just give more options to our users. 😀

Is the requirement just wrapping this try clause using SafeCloseable ?

The RequestContext.push() already returns SafeCloseable.
I meant if a user wants to execute a function or code with RequestContext, he/she can do it by:

// 1. use makeContextAware()
// wrap the given Runnable with request context
Runnable contextAwareRunnable = ctx.makeContextAware(() -> {
    logger.trace(decorate(msg));
});
...

// can execute returned Runnable with request context later
contextAwareRunnable.run();

// 2. or use push()
// immediately push current request context to context storage such as ThreadLocal 
try (SafeCloseable ignored = ctx.push()) {
    logger.trace(decorate(msg));
}

I think we can give users another option.

Runnable r = () -> {
   // some logic should run with request context
}

ctx.run(r);

This seems a shortcut for ctx.makeContextAware(r).run(), but it can avoid creating additional Runnable.
And I think we can also support this for other functional interfaces i.e, Supplier, Callable... 😀

I am still not sure why this feature is required.

This issue is for providing handy interfaces ?

You said that this can be reduced additional runnable interface creation. (Maybe reusing existing runnable instance, right?) Still, I could not come up easily the situation is.