fix(model): register ListRecord.Field adapter in GsonFactory

[bkyryliuk]

Addresses #1653 (follow-up to #1587).

#1590 added GsonListRecordFieldFactory so that ListRecord.Field.message accepts the array shape that Slack Lists return. But the factory was only in slack-api-model/src/test, and only the test GsonFactory registered it. The production com.slack.api.util.json.GsonFactory never registered it. So on 1.49.0 through 1.52.0, conversations.replies still fails on any thread that has a Slack List unfurl:

JsonSyntaxException: Expected BEGIN_OBJECT but was BEGIN_ARRAY at path
$.messages[N].attachments[0].list_record.record.fields[M].message

Reported in #1587 (follow-up on 1.50.0) and reproduced against a live workspace in #1644.

This PR:

• Moves GsonListRecordFieldFactory from slack-api-model/src/test/java/test_locally/util/list/ to slack-api-model/src/main/java/com/slack/api/util/json/. This is where the other model adapters live, such as GsonListViewGroupingFactory. The package does not change, so the model test GsonFactory still compiles.
• Registers it in GsonFactory.registerTypeAdapters for ListRecord.Field.
• Adds GsonListRecordFieldFactoryTest in slack-api-client. It parses a conversations.replies response through the production GsonFactory, for both the array and the single-object message shapes.

There is no API change: this activates the getMessages()/setMessages() behavior that #1590 already shipped. #1637 (draft, MessageRef) can replace the adapter when it lands.

Category (place an x in each of the [ ])

• bolt (Bolt for Java)
• bolt-{sub modules} (Bolt for Java - optional modules)
• slack-api-client (Slack API Clients)
• slack-api-model (Slack API Data Models)
• slack-api-*-kotlin-extension (Kotlin Extensions for Slack API Clients)
• slack-app-backend (The primitive layer of Bolt for Java)

Requirements

Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you agree to those rules.

This pull request and its description were written by Isaac.

[salesforce-cla]

Thanks for the contribution! Before we can merge this, we need @bkyryliuk to sign the Salesforce Inc. Contributor License Agreement.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.89%. Comparing base (699b7eb) to head (9bea9ac).
⚠️ Report is 1 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #1654      +/-   ##
============================================
- Coverage     72.90%   72.89%   -0.01%     
- Complexity     4593     4599       +6     
============================================
  Files           483      484       +1     
  Lines         14565    14590      +25     
  Branches       1520     1524       +4     
============================================
+ Hits          10618    10635      +17     
- Misses         3044     3050       +6     
- Partials        903      905       +2     

Flag	Coverage Δ
jdk-14	72.89% <100.00%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

[srtaalej]

thanks @bkyryliuk, and thanks for tracking down why #1590 didn't fix this in production. you're right that the adapter only ever ran in the test GsonFactory. I confirmed it locally: your Repro throws on main and parses fine on this branch.

we're going to close this one in favor of #1637, though. Our live API probes (#1644, #1637) found that message on list fields is always an array, and that each element is a message reference shaped like {value, channel_id, ts, thread_ts?}, not a full chat Message. With this PR, parsing succeeds, but value (the permalink) and channel_id get silently dropped. With failOnUnknownProperties=true, it still fails with Unknown property detected: value. #1637 types the field as List<MessageRef> and removes this adapter, so we'd rather ship the correct model once than merge code we'll remove in the next release.

your test is really useful, though! It parses conversations.replies through the production GsonFactory, which is exactly the coverage that would have caught this regression. We'll carry that approach into #1637 using the real reference shape. Thanks again for pushing on this!

[bkyryliuk]

Thanks @srtaalej for checking the repro and for the clear explanation. Shipping the correct MessageRef model once in #1637 makes sense.