feat: add webapi response changes as of 2026-08-22

[slackapi]

This PR updates the web API client and model based on the production E2E test results.

Category

• slack-api-model (Slack API Data Models)

Requirements

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 72.84%. Comparing base (b7562e3) to head (bdc25cf).
⚠️ Report is 3 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #1636      +/-   ##
============================================
- Coverage     72.87%   72.84%   -0.04%     
- Complexity     4522     4533      +11     
============================================
  Files           479      482       +3     
  Lines         14390    14423      +33     
  Branches       1503     1512       +9     
============================================
+ Hits          10487    10506      +19     
- Misses         3013     3022       +9     
- Partials        890      895       +5     

Flag	Coverage Δ
jdk-14	72.84% <ø> (-0.04%)	⬇️

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.

[zimeg]

⚠️ EXPERIMENTAL — Slack Lists message field re-typed as List<MessageRef> (388afd370)

Pushed an experimental change to how ListRecord.Field.message is modeled. Not final — do not merge as-is. Flagging it here with full context for review.

What changed

ListRecord.Field.message is now List<ListRecord.MessageRef> where MessageRef = { value, channel_id, ts, thread_ts? }. The prior Message-typed modeling (#1590) is replaced; the test-tree GsonListRecordFieldFactory is reduced to a pass-through and its tests rewritten against the new shape.

Why — verified against the live API

The response shape was confirmed empirically on two surfaces, across single/threaded/multi-reference scenarios:

• slackLists.items.list
• the nested list_record attachment returned by conversations.history / conversations.replies

Both return the message field as [{ "value": "<permalink>", "channel_id": "C…", "ts": "…", "thread_ts"?: "…" }] — always an array, with thread_ts present only when the referenced message is a threaded reply. No single-object form was observed on either endpoint. Element is a message reference, not a chat message. Field-type reference: slackLists.items.create#field-types.

This means the earlier Message element type did not match the payload, and the single-object↔array normalization added in #1590 handled a shape the API does not actually return on these endpoints.

Open question (the reason this is experimental)

This fixes the response only. The request side of the field takes an array of permalink URL strings (List<String>) — verified: the API rejects object form with must provide a string [json-pointer:/initial_fields/0/message/0]. A single Field.message type cannot serve both directions. The request/response split still needs a design decision (direction-aware types, or bring Lists types under codegen). This is the same request-vs-response tension previously seen on the Node side.

Related / for later reference

• #1590 — the earlier Java array-deserialization fix (runtime crash) that this supersedes on the model side.
• java-slack-sdk ListRecord.Field.message` deserialization fails when Slack returns an array #1587 — the runtime JsonSyntaxException on array-shaped message; fixed (that was a crash; distinct from this typing question).
• node-slack-sdk #2598 — the analogous Node bug: the generated response type is wrong for this field. This model fix is the upstream half of resolving it (Node response types generate from Java samples).
• node-slack-sdk #2599 / #2600 — hand-split attempts at #2598 that modeled Message | Message[]; obsolete — they used the wrong element type and an unnecessary union (the field is array-only, and the element is a reference, not a Message).

Verification was done against a test workspace; a few throwaway probe lists (clack probe …) were created there and can be cleaned up.