# Patching tracing into Polkadot v29

substrate branch: zeke-add-traces-polkadot-v0.8.29
polkadot branch: zeke-29-port-rpc-trace

## Tue, March 16th

Branched from polkadot-v0.8.29 and add in the block trace RPC

## Wed, March 17th

### overview
I put several `trace::trace!` and `log::info!` messages in client/tracing/src/block/mod.rs.

Currently polkadot is not yet in runtime v29 - it is in v28. As of now I get no spans when querying runtimes that are not the same as the client. So I am getting no spans, but I am getting events from state-machine/ext.rs
*I would query Kusama since it has been updated but I am still waiting on the archive node to synce.

I am using the following options to run the node:

 cargo run --bin=polkadot -- --pruning=archive --base-path=/home/zeke/nodebases/test-1 --rpc-methods=Unsafe --chain=polkadot --wasm-runtime-overrides=/home/zeke/substrate-archive/wasm-tracing/polkadot

### wasm runtimes from archive
I also pointed the node at the wasm runtimes with tracing substrate archive. Even when I query blocks in those runtimes I do not get spans.
**BUT** the events do have `parent_id`, which they do not have in the runtimes we don't have wasm from for archive. This indicates to me there are spans but

### (naieve) notes on what I saw from logging and tracing

- No `log::info!` messages I put in the `Subscriber` showed up
- ex: https://github.com/paritytech/substrate/blob/bb0c8b6db8d082491c4596c62a090eda7e30b01c/client/tracing/src/block/mod.rs#L133

- [The `trace::trace!` I put in `BlockSubscriber::new_span` does not show up](https://github.com/paritytech/substrate/blob/bb0c8b6db8d082491c4596c62a090eda7e30b01c/client/tracing/src/block/mod.rs#L96)
- I would guess putting `trace::trace!` in `BlockSubscriber::event` would succesfully create an event, but I didn't do it since I assume it would create an infinite loop

- `log::info!` _outside_ of `dispatcher::with_default` consistenly show up, [such as here](https://github.com/paritytech/substrate/blob/bb0c8b6db8d082491c4596c62a090eda7e30b01c/client/tracing/src/block/mod.rs#L232)

- conversly, `log::info!` _inside_ of `dispatcher::with_default` does not show up, [such as here](https://github.com/paritytech/substrate/blob/bb0c8b6db8d082491c4596c62a090eda7e30b01c/client/tracing/src/block/mod.rs#L245)

- [`trace::trace!` does show up within `dispatcher::with_default`](https://github.com/paritytech/substrate/blob/bb0c8b6db8d082491c4596c62a090eda7e30b01c/client/tracing/src/block/mod.rs#L248)

### next steps

- Make querys in a v29 runtime to confirm the trace spans show up
- Iff possible, see if I can enter a span prior to `dispatcher::with_default`. If this is possible I am guessin the span might show up, but haven't read docs here
- Read more into how dispatcher works and really actually for real figure out why spans are not showing up at all
- Clarify understanding of runtime and client communication

## Thur, March 18th

### notes (ignore)

- Dispatcher
- dispatcher::with_default
- will not propgate the current threads default subscriber to spawned threads

### next steps

- Understand wasm tracing code

## Fri, March 19th

- https://github.com/paritytech/substrate/pull/5698
- Tracing is introduced to the decl_module macro in april 2020
- Makes me think spans from within decl_module should show up