Error Handling & Debugging

9. Error Handling & Debugging

This section outlines how W3S handles errors in incoming messages and provides guidance for logging, diagnostics, and rejection behavior.

---

Validation Errors

If a message fails schema validation (based on its MessageTypeId):

• The message is rejected silently by default.
• Optionally, an error message may be sent back to the sender depending on system configuration.

Typical validation failures include:

• Missing or unknown MessageTypeId
• Invalid Payload structure or missing required fields
• Mismatched DeviceId or malformed metadata

---

Authorization Failures

If a message is not permitted based on the sender’s role, device mapping, or constraints:

• The message is dropped without response (default behavior)
• Administrators may configure logging or alerting for audit purposes

---

Transport & Framing Errors

For binary messages:

• If the JSON header cannot be parsed, the entire message is rejected
• If the declared JSON header length is invalid (e.g., too long or inconsistent), the message is discarded

Additional safety mechanisms include:

• Maximum size limits on JSON headers and binary payloads
• UTF-8 validation of the header section

---

Debugging Tools & Internal Logging

• W3S logs rejected messages internally with reasons (e.g., schema error, permission denied, parse error)
• Debug logs can be filtered by MessageTypeId, sender DeviceId, or user
• Optional debug MessageTypeIds (e.g., DEBUG_TRACE_EVENT) may be available for development environments

---

Notes

• Logging and rejection behavior can be tuned based on environment (e.g., dev vs production)
• Error responses are never sent to OSS8 devices to reduce network noise and risk of log flooding
• Client-facing applications may receive structured error responses if enabled