The crown jewel of the Grat project is the Replay Engine, a complex system designed to pull historical transactions and simulate them locally to generate rich debugging metrics. The core of this system is the execute_with_tracing function located in sandbox.rs. This function is supposed to instantiate an isolated virtual machine, feed it the initial ledger state, and execute the contract to record events. However, upon inspection, the function is nothing more than a hollow shell. It immediately logs "Sandbox execution with tracing, not yet implemented" and returns a hardcoded error. This means that anytime the backend attempts to process a replay job, it hits a brick wall. The most advanced analytical feature of the software simply does not exist yet, rendering the entire concept of local simulation completely inaccessible.
Issues/what to fix
This is a massive structural gap that requires a comprehensive implementation phase. The execute_with_tracing function must be completely written from scratch. This involves integrating the soroban env host crate. The engine must establish a custom Storage interface that bridges the host environment with Grat's captured LedgerState. Furthermore, a deep instrumentation layer must be injected into the host's execution lifecycle so that every internal event (e.g., CPU gas ticks, memory allocations, cross contract calls) is intercepted and logged into a chronological TraceEvent array. Finally, the function must gather the mutated state maps and return a fully populated SandboxResult.
Files location
crates/core/src/replay/sandbox.rs
Expected result
The replay engine will transition from a broken stub into a fully operational execution environment. Developers will be able to take any transaction hash from the mainnet, run it through Grat, and receive a highly accurate, step by step breakdown of exactly how the contract executed within the simulated sandbox.
Contributor telegram group
https://t.me/+sII7WPhll2liMGNk
The crown jewel of the Grat project is the Replay Engine, a complex system designed to pull historical transactions and simulate them locally to generate rich debugging metrics. The core of this system is the execute_with_tracing function located in sandbox.rs. This function is supposed to instantiate an isolated virtual machine, feed it the initial ledger state, and execute the contract to record events. However, upon inspection, the function is nothing more than a hollow shell. It immediately logs "Sandbox execution with tracing, not yet implemented" and returns a hardcoded error. This means that anytime the backend attempts to process a replay job, it hits a brick wall. The most advanced analytical feature of the software simply does not exist yet, rendering the entire concept of local simulation completely inaccessible.
Issues/what to fix
This is a massive structural gap that requires a comprehensive implementation phase. The execute_with_tracing function must be completely written from scratch. This involves integrating the soroban env host crate. The engine must establish a custom Storage interface that bridges the host environment with Grat's captured LedgerState. Furthermore, a deep instrumentation layer must be injected into the host's execution lifecycle so that every internal event (e.g., CPU gas ticks, memory allocations, cross contract calls) is intercepted and logged into a chronological TraceEvent array. Finally, the function must gather the mutated state maps and return a fully populated SandboxResult.
Files location
crates/core/src/replay/sandbox.rs
Expected result
The replay engine will transition from a broken stub into a fully operational execution environment. Developers will be able to take any transaction hash from the mainnet, run it through Grat, and receive a highly accurate, step by step breakdown of exactly how the contract executed within the simulated sandbox.
Contributor telegram group
https://t.me/+sII7WPhll2liMGNk