Skip to content

Conversation

@marioevz
Copy link
Collaborator

@marioevz marioevz commented Jan 28, 2026

🗒️ Description

Moves the cache to be managed by the T8N itself with help from the filler instead of managed by the test spec.

Steps:

  • Filler determines the cache-key, which is computed from a new property of the fixture format called transition_tool_cache_key.
  • The field is set to the same value in BlockchainFixture and BlockchainEngineFixture.
  • When the value is detected in format for the test currently being filled, the filler checks whether the cache already existed inside of the t8n instance and, if it matches the key, the cache is reused, otherwise it's cleared or reset.
  • T8N now internally checks for the presence or absence of the cache, if it exists, it automatically returns the cached output for the current "subkey".
  • The "subkey" is now the t8n call counter insted of the block number in the environment (it could be that a test generates a different block in the same number to, e.g., simulate a re-org).
  • The filler, when the test finishes, resets the t8n instance for the next test.

All t8n related fields have also been removed from the test spec instance and have been moved to the t8n instance for the filler to reset/setup.

The output cache of the TransitionTool object is also now unbounded, which allows for tests with arbitrary number of blocks to be cached, but it's completely cleared by the filler if the test following immediately afterwards does not match the cache key.

@marioevz marioevz requested a review from danceratopz January 28, 2026 00:14
Copy link
Owner

@danceratopz danceratopz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @marioevz! I had the cache in the t8n tool instead of the spec first, too!!! I thought that having it in the spec would allow better cache garbage collection as we'd have higher-level knowledge of the test format being generated, but in the end landed up not using it. This approach is better and will extending it to other formats trivial. Let's do it!

There's a few issues here, some of which were present in:

So yes, I agree this approach is better, but this version suffers from sporadic cache misses.

I'll fix them up in the original PR and then you can review there!

@danceratopz danceratopz merged commit 337b793 into danceratopz:t8n-call-cache-specs Jan 29, 2026
9 of 15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants