Conversation
|
Hey i realized maybe we can have some other Unit tests to further verify the behaviour Empty CustomPayload ObjectWhat to test:A message with "customPayload": {} (present but empty) Expected behavior:getCustomPayload() returns an empty JSONObject, not null Serialization Round-Trip with Null CustomPayloadWhat to test:
Expected behavior:The toJSONObject() method uses putOpt() which has specific null-handling behavior. We need to ensure null values are preserved correctly through serialization cycles, not accidentally converted to empty objects or causing the field to appear in JSON when it shouldn't. CustomPayload Over Legacy PayloadLines 355-357 show fallback logic: if (customPayload == null) {
customPayload = contentJson.optJSONObject(ITERABLE_IN_APP_LEGACY_PAYLOAD);
}We need to verify that only a truly missing field triggers the legacy fallback, not an explicitly null or empty value jsonOnly Mode with Null CustomPayloadWhat to test:A message with Expected behavior:Lines 343-345 have special handling: if (customPayload == null && jsonOnly) {
customPayload = new JSONObject();
}This means:
This edge case should be explicitly tested to document this intentional difference in behavior between jsonOnly and regular messages. |
🔹 Jira Ticket(s) if any
✏️ Description
HTML-only in-app messages without a
customPayloadfield were causing crashes due to@NonNullannotation enforcement. This affected customers using the HTML-only template option (vs. the "Everything" format).Changes
customPayloadfrom@NonNullto@Nullablein:getCustomPayload()return typetestHtmlMessageWithoutCustomPayloadto cover this scenario🚨 Breaking change for Kotlin consumers 🚨 — callers of
getCustomPayload()must now handle nullability. Java consumers are unaffected at compile time but should add null checks.