Slack API issues with deserializing api payloads

[rasharab]

For one of our customers, we hit this deserialization issue with 1.45.2 of the sdk.

Got an exception while calling conversations.history API (team: ****, error: java.lang.IllegalStateException: Not a JSON Object: [])

j.l.IllegalStateException: Not a JSON Object: [] at c.g.gson.JsonElement.getAsJsonObject(JsonElement.java:165) at c.s.a.u.j.GsonFileFactory.deserialize(GsonFileFactory.java:46) at c.s.a.u.j.GsonFileFactory.deserialize(GsonFileFactory.java:8) at c.g.g.i.b.TreeTypeAdapter.read(TreeTypeAdapter.java:95) at c.g.g.i.b.ReflectiveTypeAdapterFactory$2.readIntoField(ReflectiveTypeAdapterFactory.java:267) at c.g.g.i.b.ReflectiveTypeAdapterFactory$FieldReflectionAdapter.readField(ReflectiveTypeAdapterFactory.java:558) at c.g.g.i.b.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:516) ... 40 common frames omitted Wrapped by: c.g.g.JsonSyntaxException: java.lang.IllegalStateException: Not a JSON Object: [] at c.g.g.i.b.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:520) at c.google.gson.Gson.fromJson(Gson.java:1361) at c.google.gson.Gson.fromJson(Gson.java:1463) at c.google.gson.Gson.fromJson(Gson.java:1434) at c.g.g.i.b.TreeTypeAdapter$GsonContextImpl.deserialize(TreeTypeAdapter.java:199) at c.s.a.u.j.GsonLayoutBlockFactory.deserialize(GsonLayoutBlockFactory.java:31) at c.s.a.u.j.GsonLayoutBlockFactory.deserialize(GsonLayoutBlockFactory.java:12) at c.g.g.i.b.TreeTypeAdapter.read(TreeTypeAdapter.java:95) at c.g.g.i.b.TypeAdapterRuntimeTypeWrapper.read(TypeAdapterRuntimeTypeWrapper.java:40) at c.g.g.i.b.CollectionTypeAdapterFactory$Adapter.read(CollectionTypeAdapterFactory.java:83) at c.g.g.i.b.CollectionTypeAdapterFactory$Adapter.read(CollectionTypeAdapterFactory.java:59) at c.g.g.i.b.ReflectiveTypeAdapterFactory$2.readIntoField(ReflectiveTypeAdapterFactory.java:267) at c.g.g.i.b.ReflectiveTypeAdapterFactory$FieldReflectionAdapter.readField(ReflectiveTypeAdapterFactory.java:558) at c.g.g.i.b.ReflectiveTypeAdapterFactory$Adapter.read(ReflectiveTypeAdapterFactory.java:516) at c.g.g.i.b.TypeAdapterRuntimeTypeWrapper.read(TypeAdapterRuntimeTypeWrapper.java:40) at c.g.g.i.b.CollectionTypeAdapterFactory$Adapter.read(CollectionTypeAdapterFactory.java:...

[misscoded]

Hi @rasharab! Thanks for raising this issue. We'll be looking into this shortly and will circle back with you once we've had the chance to investigate + reproduce it.

[rasharab]

Just an FYI, we only hit this with one distinct customer while attempting to iterate messages from one of their slack channels, so I'm not sure how best we can create a repro for you guys.

[WilliamBergamin]

@rasharab by any chance would you have the payload of the response that did not get parsed properly? Based on this error message it is hard to tell what field was affected, but it does seem like an object was expected and an array was given

[rasharab]

I do not. I'm just relaying to you guys what's outputted by in our logs: com.slack.api.methods.impl.AsyncRateLimitExecutor

Haven't investigated that code, but might be worthwhile outputting the payload when it fails to deserialize.

[seratch]

This appears similar to the issue you reported at https://github.com/slackapi/java-slack-sdk/issues/1426 in the past. It's a problem specific to the Slack API's dynamic data structure, which can return entirely different data types for the same property name. Indeed, it might be worthwhile to share which property doesn't match, even in the production logs. If the team would like me to explore this, I may be able to work on it in my spare time.

[rasharab]

Dead on, this is guraanteed to happen again for us, and from an end user's perspective, the more information we can hand off to you guys easily via your logs, the better for us.

[github-actions[bot]]

👋 It looks like this issue has been open for 30 days with no activity. We'll mark this as stale for now, and wait 10 days for an update or for further comment before closing this issue out. If you think this issue needs to be prioritized, please comment to get the thread going again! Maintainers also review issues marked as stale on a regular basis and comment or adjust status if the issue needs to be reprioritized.