Type inference results in `overflow evaluating the requirement`

The full reproducible case is here. Before committing further efforts on reducing it I would like to learn about maintainer's opinion on such issues. Whether it should be considered as bug? If so, will it be fixed straight way or need to go through some formalization first?

The skeleton is like this

f() {
    let (sender, mut receiver) = unbounded_channel();
    let (crypto_sender, mut crypto_receiver) = unbounded_channel();

    let crypto_task = run_worker(..., sender, crypto_receiver);

    let mut context = Context::<Of<_>, _> { ..., crypto_sender, ... };
    let client_task = run_with_schedule(..., context, receiver, ...);
    // let crypto_task = run_worker(..., sender, crypto_receiver);
}

If compiled like this it will fail with

error[E0275]: overflow evaluating the requirement `_: Sized`

(By the way, a minor issue here is that the trace does not properly fold the repeating steps. It also results in outputting hundreds of "long type" files (and even more if increasing recursion limit).)

If switch to define crypto_task at the commented location, it just compiles. The crypto_task and client_task are independent definitions so it is semantically same to define in either order (in my original case they are futures so even nothing executed effectively by this two definitions).

Giving annotation to the first unbounded_channel() call with at least ::<ErasedEvent<State<()>, _> makes it compile in the original order.

It has always been the case where type inference does not work in some definition order, but most of the time a "type annotation required" error is reported. Should we fix this case to the extent that at least a less confusing error is reported? On the other hand I am actually curious about the internal mechanism here:

• As shown later in the error message compiler starts by checking for Send, but eventually get stuck in checking Sized, what's happening here?
• How does the extra information provided by the alternative definition order help compiler bypass an infinite loop? The two seems unrelated to me, if there is supposed to be an infinite check, there will always be.

Thanks for any clarification!

Meta

rustc --version --verbose:

rustc 1.79.0 (129f3b996 2024-06-10)
binary: rustc
commit-hash: 129f3b9964af4d4a709d1383930ade12dfe7c081
commit-date: 2024-06-10
host: x86_64-unknown-linux-gnu
release: 1.79.0
LLVM version: 18.1.7

Also reproduced on nightly

rustc 1.81.0-nightly (524d806c6 2024-07-05)
binary: rustc
commit-hash: 524d806c62a82ecc0cf8634b94997ae506f4d6f9
commit-date: 2024-07-05
host: x86_64-unknown-linux-gnu
release: 1.81.0-nightly
LLVM version: 18.1.7

<backtrace>

Start with the linked Rust Playground reproducer and verify the failure on the reported stable and nightly rustc versions. Compare the two definition orders and the explicit channel type annotation, then determine whether the compiler behavior or diagnostic should change.