instrument macro causes Infinite recursion

[MrFoxPro]

Bug Report

Version

0.1.41, also tried 0.1.3*

Platform

Linux 6.12 x64, rust nightly

Description

I used tracing with macros in multiple pretty big projects sucessfully, but didn't encounter such problem.

thread 'tokio-runtime-worker' has overflowed its stack
fatal runtime error: stack overflow

I spent few hours looking for cause and found that this happens because of annotating one of methods with insturment macro.

But something really weird is going on.
I have very simple logic

// message_handler
tracing::debug!("command name: {}", cmd.name);
match cmd.name.as_str() {
    "/reply" if is_admin => {
        let command_context = cmd::CommandContext { chat_id, msg, cmd, user, is_admin };
        return cmd::reply(command_context, ctx).await
    }
...
// cmd::reply
#[tracing::instrument(err, skip_all)]
pub async fn reply(CommandContext { msg, ..}: CommandContext, ctx: AppContext) -> AppResult<()> {
	let text = msg.get_text()
		.map(|x| x.data.clone())
		.unwrap_or(String::new()).replace("/reply ", "");

	let space_idx = text.find(" ")
		.ok_or(anyhow::anyhow!("text was not found"))?;

	let chat_id = text[0..space_idx].to_string();
	let text = text[(space_idx + 1)..].trim().to_string();

	SendMessage::new(chat_id.clone(), text).parse_mode("markdown")
		.exec(&ctx.bot).await?;

	SetMessageReaction::new(msg.chat.id, msg.message_id)
		.reaction([ReactionType::Emoji(ReactionTypeEmoji::new("👍", "emoji"))])
		.exec(&ctx.bot).await?;

	Ok(())
}

stack overflow happens if there is external function call in match. But when running, program doesn't even get to the match statement and does not output "command name" debug before crashing.
Replacing return cmd::reply(command_context, ctx).await with return Ok(()) fixes crash.
Seems like instrument macro breaks code flow.

What i tried:

• multiple rustc versions, from 1.81
• previous versions of tracing and tracing-subscriber
• multiple previous versions of tokio

It didn't help. I replaced tracing with fastrace + logforth + logcalls crates (they provide similiar features and macros) and there was no this issue too.

I ran cargo expand with and without instrument macro on problematic method macro:
expand_bad.rs.txt
expand_ok.rs.txt
(look for handle_update, message_handler, cmd::reply calls)

[MrFoxPro]

my hypotheses of probable cause:

• .exec uses reqwest + multipart inside, there is issue with it
• I'm using local dependency in Cargo.toml which contains large auto-generated .rs file, maybe it is somehow related to generics expansion for a large number of types and/or incorrect dependency resolution
• Using new async traits in local dependency

probably related: #3197