# EPF Cohort 6 – Week 13 Update

## Finished all challenges from past week :D

- Completed and merged [**Repository-Wide Tracing Migration & Full Network Layer Instrumentation**](https://github.com/sntntn/grandine/pull/9)
- Reviewed by [Tumas](https://github.com/Tumas) - **all tests now pass**

---

### Thread Safety Issue (resolved)

- At first, it seemed the problem appeared after I removed the `slog` bridge between the `p2p` crate and the external `eth2_libp2p` (extracted from Lighthouse version of network layer, which relies on `slog`)
- The initial guess was that removing the log from message passing caused the issue, assuming the log made the messages implicitly `Send`, and masked something so without problem apeer.
- This led me to dive deeper into channels, fearless concurrency, locks and related topics (*see my previous [update](https://hackmd.io/@sntntn/ByyZp_n5gl) — I’ll add some more useful links in Resources*).
- Since I couldn’t quickly solve it without deeper experimental changes, I asked [Tumas](https://github.com/Tumas) for help. He first had the same assumption, but the next day he found the real culprit and owe huge thanks for that.
- The issue is described [**here**](https://github.com/sntntn/grandine/issues/14)

---

### Consensus-spec-tests recomendatation

In one of my earlier updates ([here](https://hackmd.io/KConcC79TXu2FXbGzOQTeg?view#Current-state)), I explained a memory-saving trick for consensus clients that rely on the same submodules (e.g., `consensus-spec-tests`).

The idea was to extract such submodules into a separate location and then create **symlinks** to **reuse** them across multiple clients. This way we can **save disk space** and avoid pulling the same heavy repository multiple times.

That approach looks great at first, but when clients rely on different release versions of `consensus-spec-tests`, **things get tricky**. An incompatible version can lead to false test failures, and manually checking out between versions may even cause issues when unpacking **SSZ Snappy files** (as happened in my case).

So when working with different versions of `consensus-spec-tests`, it’s actually **safest** to **keep separate copies** and not play around with memory savings :)

Details are described in this [**issue**](https://github.com/sntntn/grandine/issues/15).

>I’ll also look into where this recommendation could be added on the Wiki for future reference.

---

## Next Steps

I received a new task that Saulius prioritized over instrumenting the core protocol (Phase 3), which means I’ll once again delay deeper exploration of the consensus client’s core logic.

The task itself is really interesting: I need to **research and implement a way to dynamically change the logging and tracing levels at runtime**.

Most likely, I’ll implement this through a custom “secret” API (not defined by the Beacon spec) — but we’ll see how it evolves.

My work will be on [feature/dynamic-tracing-config](https://github.com/sntntn/grandine/tree/feature/dynamic-tracing-config) branch.

## Resources

- [Grandine GitHub Repository](https://github.com/grandinetech/grandine)
- [Roadmap through phases](https://github.com/eth-protocol-fellows/cohort-six/blob/master/projects/Grandine-Implementing-Tokio-Tracing-For-Debugging-And-Performance-Analysis.md#roadmap)
- [**Repository-Wide Tracing Migration & Full Network Layer Instrumentation**](https://github.com/sntntn/grandine/pull/9)
- [Documentation on EnteredSpan explaining why the future wasn’t Send](https://docs.rs/tracing/latest/tracing/span/struct.EnteredSpan.html#in-asynchronous-code)
- **issues**:
- [thread safety issue](https://github.com/sntntn/grandine/issues/14)
- [Avoid sharing test submodules between multiple Grandine repositories with different versions](https://github.com/sntntn/grandine/issues/15)
- more useful links for fearless concurrency in Rust:
- [book: **Rust Atomics and Locks**](https://marabos.nl/atomics/)
- [book: **Asynchronous Programming in Rust**](https://rust-lang.github.io/async-book/intro.html)