Fix AuRaMergeEngineModuleTests

[Marchhill]

Changes

• Fix test to actually use AuRaBlockProcessor code path, previously used regular BlockProcesssor

Types of changes

What types of changes does your code introduce?

• Bugfix (a non-breaking change that fixes an issue)
• New feature (a non-breaking change that adds functionality)
• Breaking change (a change that causes existing functionality not to work as expected)
• Optimization
• Refactoring
• Documentation update
• Build-related changes
• Other: Test fix

Testing

Requires testing

• Yes
• No

If yes, did you write tests?

• Yes
• No

Documentation

Requires documentation update

• Yes
• No

Requires explanation in Release Notes

• Yes
• No

[LukaszRozmej]

2 tests are failing

[Marchhill]

@claude review

[claude]

Claude finished @Marchhill's task in 2m 48s —— View job

---

Code Review

• Gather context and read changed files
• Analyze changes and provide review feedback

---

Summary

The core fix is correct: the original MergeAuRaTestBlockchain was silently overriding the DI-registered IBlockProcessor with a plain BlockProcessor, bypassing AuRaBlockProcessor entirely. This PR removes that workaround and properly configures the AuRa dependencies. However, there are a few issues worth addressing.

---

Issues

1. Base class modification concerns (aligns with reviewer's request) — Blocking

The changes to EngineModuleTests.V1.cs (making tests virtual + adding bool isAura parameter) address an AuRa-specific need but modify the base class interface. The reviewer's question is valid: are all derived test classes now affected?

The [TestCase(false)] in the base class means that any other class inheriting from EngineModuleTests will also run these tests with an isAura=false parameter where they previously ran with [Test]. While functionally equivalent, it changes the test signatures. NUnit attribute inheritance for [TestCase] on virtual methods can also be ambiguous — derived classes that do NOT override these methods will still run with isAura=false, while AuRaMergeEngineModuleTests overrides with [TestCase(true)] to replace it.

A cleaner alternative that avoids touching the base class would be:

1. Keep the base tests as [Test] with no isAura parameter
2. In AuRaMergeEngineModuleTests, override both tests and apply [Ignore] to suppress the non-AuRa variants, then add separate [Test]-annotated methods that build blocks with .WithAura(0, []) explicitly

However, if code duplication is the concern, the current parameterized approach is defensible, provided the NUnit inheritance behavior is confirmed and there are no regressions in other derived test classes.

2. Duplicate AddDecorator<AuRaNethermindApi> in ConfigureContainer — Minor

AuRaMergeEngineModuleTests.cs lines 156–161 add a new decorator for AuRaNethermindApi to set EngineSigner and NonceManager, while lines 175–183 hold the existing decorator for TxPool, TransactionComparerProvider, and FinalizationManager. These two decorators could be merged into one for readability.

// Current — two separate decorators
.AddDecorator<AuRaNethermindApi>((_, api) =>
{
    api.EngineSigner = NullSigner.Instance;
    api.NonceManager = Substitute.For<INonceManager>();
    return api;
})
// ... other registrations ...
.AddDecorator<AuRaNethermindApi>((_, api) =>
{
    api.TxPool = TxPool;
    // ...
    return api;
});

Not a blocking issue since Autofac decorator chains work correctly, but it's an unnecessary split.

Fix this →

3. Failing tests — needs investigation

LukaszRozmej mentioned 2 tests are failing. With the CI showing no recent run results, it's hard to identify which tests these are without running them. Likely candidates are tests in AuRaMergeEngineModuleTests that inherit from the base but use blocks that don't have AuRa headers — specifically ones that go through the AuRaBlockProcessor path. The addition of ValidatorsJson and EngineSigner/NonceManager in this PR addresses some of those gaps, but any other test that builds plain Block objects (without .WithAura(0, [])) and processes them through the AuRa chain could still fail.

---

What's correct

• Removing .AddScoped<IBlockProcessor, BlockProcessor>() is the right fix — the old comment literally said "AuRa was never configured correctly in test."
• Adding ValidatorsJson with List = [Address.Zero] is necessary for AuRaContractValidator initialization.
• Setting api.EngineSigner = NullSigner.Instance and api.NonceManager = Substitute.For<INonceManager>() correctly satisfies the AuRa signing path.
• The WithGenesisPostProcessor AuRa header seeding and the block producer wiring look correct and unchanged.

---