Slack API issues with deserializing api payloads · Issue #1450 · slackapi/java-slack-sdk · GitHub
Skip to content

Slack API issues with deserializing api payloads #1450

Open

Description

@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:...

Activity

  1. added
    bugM-T: confirmed bug report. Issues are confirmed when the reproduction steps are documented
    and removed on Mar 5, 2025
  2. misscoded commented on Mar 5, 2025

    @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.

  3. rasharab commented on Mar 5, 2025

    @rasharab
    Author

    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.

  4. WilliamBergamin commented on Mar 10, 2025

    @WilliamBergamin
    Contributor

    @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

  5. rasharab commented on Mar 11, 2025

    @rasharab
    Author

    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.

  6. seratch commented on Mar 14, 2025

    @seratch
    Contributor

    This appears similar to the issue you reported at #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.

  7. rasharab commented on Mar 14, 2025

    @rasharab
    Author

    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.

  8. github-actions commented on Apr 14, 2025

    @github-actions
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    auto-triage-skipbugM-T: confirmed bug report. Issues are confirmed when the reproduction steps are documentedneeds info

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions