Adding an `.await` inside an already-async fn somehow changes the fn's type

[restive niche]

I'm working on a (fairly complex) system where I have a certain trait implemented for async fns so that I can use a trait object of this trait to store the async fns and call them later (it's for an ECS implementation similar to Bevy's, where plain rust functions act as Systems, except I'm trying to make it work with async functions as well.) In one of my asset-related systems, if I call another async function (also part of another, asset-loading-related trait) and .await it, suddenly the compiler doesn't recognize the outer system as an implementor of the trait I mentioned initially.

I can post implementation details if necessary, but my main question as per the title is, are there any kind of advanced situations (possibly involving higher ranked trait bounds) where .awaiting a future inside another async function could change the outer function's type enough to confuse the type checker?

I know this is a fairly complicated explanation, so let me know if I need to elaborate on anything. Really I just want to know if I'm looking at the right problem. Thanks in advance. :)

[cold yacht]

The usual thing that can change depending on awaits is whether the future is Send or Sync. Are those in your bounds for implementing your other trait?

[restive niche]

I'll double check that, and get back to you. Appreciate the insight.

Yeah, sure enough that did it. The function I was awaiting inside my asset loader system was declared in the trait as -> impl Future<Output = T>, not -> impl Future <Output = T> + Send + Sync. Thanks again!