fix(model): handle array format for ListRecord.Field message deserial… - #1590
Merged
Merged
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1590 +/- ##
============================================
+ Coverage 73.17% 73.31% +0.13%
- Complexity 4513 4520 +7
============================================
Files 477 478 +1
Lines 14291 14298 +7
Branches 1488 1490 +2
============================================
+ Hits 10458 10482 +24
+ Misses 2940 2929 -11
+ Partials 893 887 -6
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
WilliamBergamin
approved these changes
May 15, 2026
|
|
||
| public List<Message> getMessages() { | ||
| if (messages == null && message != null) { | ||
| return Collections.singletonList(message); |
Contributor
There was a problem hiding this comment.
Sweeet 🍬 I like this 💯
| public void setMessages(List<Message> messages) { | ||
| this.messages = messages; | ||
| if (messages != null && !messages.isEmpty()) { | ||
| this.message = messages.get(0); |
Contributor
There was a problem hiding this comment.
I'm not sure of this, but I think in most cases users will know to use getMessages if they expect multiple messages 🤔
zimeg
added a commit
that referenced
this pull request
Aug 25, 2026
The Lists item `message` field response is an array of message references,
verified against the live API on two surfaces (slackLists.items.list and the
conversations.replies/history nested list_record path): both return
List<{value, channel_id, ts, thread_ts?}>, always an array, with thread_ts
present only for threaded-reply references. No single-object form was
observed on either endpoint.
This replaces the earlier `Message`-typed modeling (#1590), whose element
type (a full chat Message) does not match the actual payload, and whose
single-object/array normalization handled a shape the API does not return.
The custom test deserializer is reduced to a pass-through and its tests are
rewritten against the verified MessageRef shape.
EXPERIMENTAL / not final: this fixes the RESPONSE shape only. The request
side of the field takes an array of permalink URL strings (List<String>),
which this single type does not model — the request/response split still
needs a design decision (see the PR discussion). Marking experimental so it
is reviewed, not merged as-is.
❤️
Co-Authored-By: Claude <svc-devxp-claude@slack-corp.com>
1 task
zimeg
added a commit
that referenced
this pull request
Aug 25, 2026
…age field + remote test coverage
Adds a Gson adapter so a single List<MessageRef> models the asymmetric Lists
message field correctly in both directions (verified against the live API):
- request: serializes each MessageRef to its `value` -> message: ["<permalink>"]
(the API rejects object form: "must provide a string")
- response: deserializes {value, channel_id, ts, thread_ts?} objects (and
tolerates bare-string elements defensively)
Registers the adapter in both the main and test GsonFactory. Extends the
remote slacklists_Test to add a message column, post a message, reference it
by permalink, and assert the echoed reference shape — so the generated sample
carries the real message field instead of a degenerate [""]. The live remote
test passes (3/3) and the raw capture shows the correct
{value, channel_id, ts} shape.
Still EXPERIMENTAL / not final (see PR discussion): this is the response/
request modeling for the message field via one type; review before merge. The
committed sample is regenerated by the runner from this capture.
Fixes the Java half of node-slack-sdk#2598 (node response types generate from
these Java samples). Supersedes the Message-typed modeling from #1590 for this
field.
❤️
Co-Authored-By: Claude <svc-devxp-claude@slack-corp.com>
1 task
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
…ization
Slack's API can return the
messagefield in ListRecord.Field as eithera JSON object or a JSON array. Previously, receiving an array caused an errorJsonSyntaxException ("Expected BEGIN_OBJECT but was BEGIN_ARRAY").Added
GsonListRecordFieldFactoryto normalize both shapes and not cause regressions on existing expected behavior. The existinggetMessage()API continues to return a singleMessage(first element), and a new getMessages() accessor provides the full list.Closes #1587
Category (place an
xin each of the[ ])Requirements
Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you agree to those rules.