Matter Bridge crashes with "type_error" in MessageHandler::msg_received on HTTP endpoint timeout

[va1dir]

Problem Description

The Matter Bridge implementation crashes completely when a bridged http_relay / http_light child device experiences network latency and times out during an attribute read/subscribe request from the Apple HomeKit hub.

Instead of marking the endpoint as offline or handling the timeout gracefully, the Berry script throws a type_error exception in MessageHandler::msg_received, which aborts the thread, drops the UDP connection with the Apple Hub, and forces the entire Matter Bridge to show as "No Response" in the Apple Home app.

Hardware & Setup

• Main Bridge: ESP32 running Tasmota 15.3.0 (Matter Bridge enabled).
• Endpoints: Several Sonoff MINIR4 devices bridged via HTTP (e.g., type:http_relay).
• Matter Hub: Apple HomePod Mini / Apple TV.

Steps to Reproduce

1. Configure an ESP32 as a Matter Bridge with http_relay endpoints.
2. Pair the bridge with Apple HomeKit.
3. Introduce network latency or a weak Wi-Fi signal to one of the child HTTP endpoints (simulating a response time > 1000ms).
4. The Apple Hub sends a Subscribe or Read_Attr request via UDP.
5. The HTTP request to the child device times out, resulting in a failed to parse JSON response payload= or HTTP timeout.
6. The Matter MessageHandler attempts to parse this empty/nil response into the TLV encoder and crashes.

The Logs (Weblog 4)

Notice the lag spike on .101, .102, .103, and .105, followed immediately by the type_error crash:

17:38:27.960 MTR: sending packet to '[192.168.0.4]:50980'
17:38:27.973 MTR: HTTP async-resp in 2011 ms from 192.168.0.105: [0] ''
17:38:27.976 MTR: *** failed to parse JSON response payload=
17:38:27.978 MTR: HTTP timeout http_status=-2 phase=2 tcp_status=-3 size_payload=0
17:38:28.001 MTR: UDP received from [192.168.0.4]:50980
17:38:28.005 MTR: decode header: local_session_id=8377 message_counter=120265168
17:38:28.010 MTR: > Decrypted message: protocol_id:1 opcode=1 exchange_id=16173
17:38:28.012 MTR: . Removed packet from sending list id=115319246
17:38:28.018 MTR: >Sub_OK ( 8377) sub=4460
17:38:28.025 MTR: <Ack* ( 8377) ack=120265168 id=115319249
17:38:28.029 MTR: sending packet to '[192.168.0.4]:50980'
17:38:28.440 MTR: HTTP async request 'http://192.168.0.102:80/cm?cmnd=Status+11'
17:38:28.454 MTR: HTTP async request 'http://192.168.0.103:80/cm?cmnd=Status+11'
17:38:28.591 MTR: UDP received from [192.168.0.4]:50980
17:38:28.595 MTR: decode header: local_session_id=8377 message_counter=120265169
17:38:28.601 MTR: > Decrypted message: protocol_id:1 opcode=1 exchange_id=16173
17:38:28.603 MTR: . Removed packet from sending list id=115319248
17:38:28.609 MTR: >Sub_OK ( 8377) sub=4460
17:38:28.616 MTR: <Ack* ( 8377) ack=120265169 id=115319251
17:38:28.620 MTR: sending packet to '[192.168.0.4]:50980'
17:38:28.717 MTR: MessageHandler::msg_received exception: type_error;operand must be bytes or int or string

[va1dir]

Proposed Fix / Root Cause
The crash happens because the Berry script lacks a strict null-check or fallback mechanism when an HTTP timeout injects a nil object during attribute expansion. The TLV encoder attempts to serialize the nil value, but it strictly expects bytes, int, or string, throwing the fatal type_error.
A try/except block or a validation check before serializing the attribute in MessageHandler.be (or returning an offline status for that specific endpoint) would prevent the entire bridge from going down during minor local network fluctuations.