# `pallet` tracing spans `target` field

@thiolliere explained the core details of this to me

In the old macro vs new macro we get slightly different targets for the tracing spans for (at least) hooks and dispatches

- Old macro: `pallet_{{pallet name}}`
- New macro: `pallet_{{pallet name}}::pallet`

## Where does the target come from in the first place

As far as I can tell the trace targets for our subset of wasm trace macros is not configurable. Thus it seems like the target come from the module_path! ([see here in the tracing crate](https://substrate.dev/rustdocs/v3.0.0/src/tracing/macros.rs.html#205))

## Where does the `::pallet` come from

In frameV2 we declare each pallet within

#[frame_support::pallet]
mod pallet {
... //declare stuff
}

So the crates name is `pallet_{{pallet name}}` and the pallet itself is declared with the module of the crate `pallet`, leading us to the path to the span `pallet_{{pallet name}}::pallet`

## Options going forward

As far as I can tell we can't manipulate the targets right where we declare the span. It simply does not seem to be an option for the wasm traces we expose. To get around this I suppose we can try to make variant of the wasm trace macro that allows us to declare the target - but this sounds heavy handed.

The two viable options that make sense to me are

1) Let it be and deal with the differences when processing the traces
2) We add a value to the trace (e.g name=pallet_name). We can get the exact name of the pallet as _its known to the runtime_. We can get that name by doing the following:

let pallet_name = <
    <T as #frame_system::Config>::PalletInfo
	as
	#frame_support::traits::PalletInfo
    >::name::<Self>().unwrap_or("<unknown pallet name>");
    
#frame_support::sp_tracing::enter_span!(
    #frame_support::sp_tracing::trace_span("on_initialize", name=pallet_name)
);

This is a bit nuanced because you can instantiate a single pallet multiple times in a runtime, and each instance of the pallet will have its own name. Currently we just go by the pallets name and not the name of the instantiated instance. An example is in order from kusama:

Council: pallet_collective::<Instance1>::{Module, Call, Storage, Origin<T>, Event<T>, Config<T>} = 14,
TechnicalCommittee: pallet_collective::<Instance2>::{Module, Call, Storage, Origin<T>, Event<T>, Config<T>} = 15,

[See here for exact lines](https://github.com/paritytech/polkadot/blob/master/runtime/kusama/src/lib.rs#L1002-L1003). With this we can allow the users of the traces to differiantiate between different instantances of the same pallet in a runtime.

The latter approach is a bit intrusive, particularly because we would need to make the changes for both the old and the new macro. Further I am still quite fuzzy on the implications on older runtimes.

For a "complete" auditable traces I think we need the pallet name as known to the runtime so we can correctly attribute state changes to a pallet. However, in the vein of minimizing intrusiveness I am currently thinking we forego this high level of fidelity; knowing we can add it in later if it becomes an issue.