Test name claims specific revert path; assertion accepts any interpreter revert
File: test/src/concrete/Flow.transfer.t.sol:311
function testFlowHaltIfEnsureRequirementNotMet() external {
(IFlowV5 flow, EvaluableV2 memory evaluable) = deployFlow();
assumeEtchable(address(0), address(flow));
(uint256[] memory stack,) = mintAndBurnFlowStack(address(this), 20 ether, 10 ether, 5, transferEmpty());
interpreterEval2MockCall(stack, new uint256[](0));
uint256[][] memory context = LibContextWrapper.buildAndSetContext(
new uint256[](0), new SignedContextV1[](0), address(this), address(flow)
);
interpreterEval2RevertCall(
address(flow), LibEncodedDispatch.encode2(evaluable.expression, FLOW_ENTRYPOINT, FLOW_MAX_OUTPUTS), context
);
vm.expectRevert("REVERT_EVAL2_CALL");
flow.flow(evaluable, new uint256[](0), new SignedContextV1[](0));
}
Claimed behavior
Test name testFlowHaltIfEnsureRequirementNotMet claims the flow halts specifically when an ensure requirement (rainlang ensure(...) opcode) fails.
Actual behavior
The test mocks IInterpreterV2.eval2 to revert with the literal string "REVERT_EVAL2_CALL". This is a generic interpreter-revert propagation test — it would pass for any eval2 revert (out-of-gas, stack underflow, division-by-zero, runtime opcode error, etc.), not the specific ensure-failure path the name describes. There is nothing in the test that pins the revert origin to an ensure opcode.
Proposed correction
Either:
- Rename to reflect actual coverage:
testFlowRevertPropagatesFromInterpreter / testFlowHaltsOnEvalRevert. Drop the ensure-specific framing.
- Leave the name and add a real ensure-path test that pins the revert payload to whatever the interpreter emits when
ensure(0, "msg") fires (if an integration-level test is feasible without mocking the entire interpreter).
Severity
INFO — the test passes for the right category of behavior (interpreter revert propagation). The name overspecifies; a reader looking for ensure-coverage will find this test and assume the case is covered when only generic propagation is.
Test name claims specific revert path; assertion accepts any interpreter revert
File:
test/src/concrete/Flow.transfer.t.sol:311Claimed behavior
Test name
testFlowHaltIfEnsureRequirementNotMetclaims the flow halts specifically when anensurerequirement (rainlangensure(...)opcode) fails.Actual behavior
The test mocks
IInterpreterV2.eval2to revert with the literal string"REVERT_EVAL2_CALL". This is a generic interpreter-revert propagation test — it would pass for any eval2 revert (out-of-gas, stack underflow, division-by-zero, runtime opcode error, etc.), not the specific ensure-failure path the name describes. There is nothing in the test that pins the revert origin to anensureopcode.Proposed correction
Either:
testFlowRevertPropagatesFromInterpreter/testFlowHaltsOnEvalRevert. Drop theensure-specific framing.ensure(0, "msg")fires (if an integration-level test is feasible without mocking the entire interpreter).Severity
INFO — the test passes for the right category of behavior (interpreter revert propagation). The name overspecifies; a reader looking for ensure-coverage will find this test and assume the case is covered when only generic propagation is.