TLVParser does not enforce max_frames limit inherited from BaseParser

[Chayashree-BR]

Summary

TLVParser does not enforce the max_frames limit inherited from BaseParser and continues parsing frames beyond the configured threshold. BinaryFrameParser correctly stops parsing when the frame limit is reached, but TLVParser does not, leading to inconsistent behavior across parser implementations.

Reproduction

from sigflow.parsers.tlv import TLVParser
from sigflow.core.context import ExecutionContext
import struct

data = b""

for i in range(5):
data += struct.pack(">HH", i, 1) + b"A"

parser = TLVParser(max_frames=2)
frames = parser.parse(data, ExecutionContext({}))

print(len(frames))

Expected Behavior

Expected output: 2
the parser should have stopped after reaching the max_frame limit

Actual Behavior

Actual output:
Actual output:5
Parsing continued beyond the limit.

Environment

• Python version: 3.12.0
• sigflow version or commit: sigflow-0.1.0
• Operating system: Windows

Additional Context

During investigation, BaseParser was observed to define a configurable max_frames limit. BinaryFrameParser enforces this limit by stopping parsing and issuing a diagnostic warning when the threshold is reached.
However, TLVParser currently appears not to apply a similar check before appending frames. This results in behavior that differs across parser implementations. This may allow larger TLV streams to continue generating frames beyond the configured threshold, potentially increasing resource usage and bypassing the intended safeguard.

[jmestwa-coder]

I can reproduce the behavioral difference between BinaryFrameParser and TLVParser regarding max_frames.

Before moving toward a fix, I’d like to better confirm the intended semantics here:

• whether max_frames is expected to be enforced consistently across all parser implementations,
• or whether TLVParser intentionally allows unbounded frame extraction for TLV streams.

If you investigate further, please also check whether other parser implementations follow the same contract and whether early termination is considered the intended behavior at the framework level.

[Chayashree-BR]

I checked the other parser implementations as well. BinaryFrameParser enforces max_frames, while TLVParser and LegacyParser do not appear to enforce it. ProtocolParser delegates to the underlying parser.
The current implementation, seem to handle max_frames differently across parsers.

[jmestwa-coder]

That makes the current behavior look more like an inconsistency in parser semantics rather than an isolated issue in TLVParser. Since BinaryFrameParser enforces max_frames while TLVParser and LegacyParser currently do not, we should first clarify which behavior is intended at the framework level before standardizing implementations.

In particular, it would be good to confirm whether:

• max_frames is expected to act as a global parser contract inherited from BaseParser,
• or whether individual parsers are intentionally allowed to interpret or ignore it differently.

Once that direction is clear, we can decide whether the correct fix is:

• adding enforcement to the remaining parsers,
• centralizing enforcement in shared logic.

[Chayashree-BR]

I agree that confirming the intended framework-level behavior first would help avoid assuming that all parsers should handle max_frames in the same way.
From the current implementation, different parsers are handling it differently, so clarifying whether it is intended as a shared parser contract or parser-specific behavior would help determine the right direction.

[jmestwa-coder]

I agree this currently behaves inconsistently across parser implementations, and max_frames should be treated as a shared parser-level safeguard inherited from BaseParser.

TLVParser and LegacyParser should likely enforce the limit similarly to BinaryFrameParser.

[jmestwa-coder]

LGMT now, raise a PR