Skip to content

[A02-4] [INFO] Live errors UnsupportedFlowInputs/InsufficientFlowOutputs lack NatSpec #280

@thedavidmeister

Description

@thedavidmeister

Description

Errors at src/error/ErrFlow.sol:26-31 carry no NatSpec, while errors above them (UnregisteredFlow, Unsupported*Flow, BurnerNotOwner) all have a /// Thrown when ... comment. The two groups of errors look intentionally split — first block annotated, second block bare — but there's no signal to a reader why.

error UnsupportedHandleTransferInputs();
error InsufficientHandleTransferOutputs();
error UnsupportedTokenURIInputs();
error InsufficientTokenURIOutputs();
error UnsupportedFlowInputs();
error InsufficientFlowOutputs();

UnsupportedFlowInputs and InsufficientFlowOutputs are reverted from Flow.sol:204 / :207 and are part of the live surface; they need at least one-line NatSpec stating the trigger condition (input count constraint vs output count constraint) so integrators can distinguish them. The Insufficient*Outputs / Unsupported*Inputs pair naming is similar enough to invite confusion when caught.

Location

src/error/ErrFlow.sol:26-31

Proposed fix

Add NatSpec stating the trigger condition for each error that survives the unused-errors cleanup:

+/// Thrown when a flow expression is registered with a non-zero input count.
 error UnsupportedFlowInputs();
+/// Thrown when a flow expression evaluation produces fewer stack items than
+/// `MIN_FLOW_SENTINELS`.
 error InsufficientFlowOutputs();

Same pattern for any of UnsupportedHandleTransferInputs / InsufficientHandleTransferOutputs / UnsupportedTokenURIInputs / InsufficientTokenURIOutputs that are kept. Errors that are dropped in the unused-errors finding don't need annotation.

Metadata

Metadata

Assignees

No one assigned

    Labels

    auditAudit findinginfoSeverity: infopass1Audit Pass 1: Security

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions