Bug | Fix message parser crash path on malformed payloads

[AnnaSasDev]

Severity

High (major feature broken)

Describe the bug

InfiniFrameWindowMessageHandlers.ParseMessage assumes valid delimiter structure and indexed split parts, so malformed input can cause index/access exceptions (for example empty segments or delimiter-only messages).
This can break the dispatch pipeline instead of failing safely.

Steps to reproduce

1. Send malformed message payload such as ";" (or other empty-delimiter forms).
2. Invoke InfiniFrameWindowMessageHandlers.ParseMessage through normal handling path.
3. Observe exception caused by split/index assumptions (for example split[0] access on invalid structure).

Expected behavior

Malformed messages are rejected safely with non-throwing parse failure semantics (for example TryParse result), and dispatch continues for subsequent valid messages.

Actual behavior

Parser can throw on malformed input and interrupt message dispatch flow.

Logs / Error Output

Potential index exceptions during message handling.

Minimal reproduction

Call Handle(window, ";") and confirm parser exception path.

.NET Version

Likely runtime-agnostic; issue is parser logic.
Please validate across supported target frameworks in this repo.

Project Version / Commit

Please reproduce on current main and attach exact commit SHA during triage.

Operating System

Expected cross-platform (Windows/macOS/Linux) because parser behavior is platform-independent.

Hardening / Proposed fix

Refactor parser to explicit, defensive contract parsing:

• Guard null/empty/whitespace input before split/access.
• Avoid direct index assumptions; validate segment count and required fields first.
• Implement non-throwing parse API (TryParseMessage) returning structured failure reason.
• Route malformed input to warning/telemetry path, not exception path.
• Enforce max message length and basic schema checks for safety.

If migrating to JSON envelope contract, keep temporary compatibility parser with strict validation and clear malformed-input handling rules.

Test plan

Add parser robustness tests:

• null, empty, whitespace-only input.
• Delimiter-only input (for example ";").
• Missing id/payload segments.
• Extra delimiters and malformed variants.
• Valid message still parses correctly.
• Dispatch flow remains alive after malformed message (no unhandled exception).

Scope / Impact

Impacts core message handling reliability and can cause high-severity runtime instability when receiving malformed/hostile input.

Checklist

• I searched existing issues
• I can reproduce this consistently
• I included logs and/or a reproduction
• Includes defensive parsing and non-throwing API direction
• Includes malformed-input regression test expectations