* Fixes a crash when an event comes in without escaped data json … #339
Conversation
…member. * update to com.google.code.gson:gson:2.9.1 * update to org.java-websocket:Java-WebSocket:1.5.3
| return new Gson().toJson(this); | ||
| } | ||
|
|
||
| public static PusherEvent fromJson(String json) { |
There was a problem hiding this comment.
How about adding tests to it? Is there a way to reproduce the problem in a test case?
serialze nulls
Codecov ReportBase: 74.50% // Head: 74.63% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #339 +/- ##
============================================
+ Coverage 74.50% 74.63% +0.12%
- Complexity 361 362 +1
============================================
Files 48 48
Lines 1957 1963 +6
Branches 147 144 -3
============================================
+ Hits 1458 1465 +7
Misses 433 433
+ Partials 66 65 -1
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
There was a problem hiding this comment.
This solution won't fix the problem for all users.
The situation:
There are users receiving JSON objects in place of strings. This is not standard. The other example for this that I have seen was someone using this SDK with another mostly pusher compatible server. Regardless, these users are calling getProperty("data") and retrieving an Object.
- On 2.40, this call would return an arbitrary
Object. - With 2.41, this was broken, because we now explicitly extract a
Stringupfront, so it crashes with arbitrary objects in thedatafield. - With this patch, we accept other types (besides
String) and convert them to aString. However, this pushes the problem further down. CallinggetProperty("data")will return aString(under the typeObject), which is not what 2.40 is doing.
In my opinion, we should either
- leave it as is and investigate why plain objects are being passed. If this is coming from one of our SDKs, it should be fixed. This leaves it broken for people who are purposefully or not using non-standard behaviour.
- revert to the previous code in this class where we didn't actively extract the field upfront
…member.
CC @pusher/mobile