[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

❌ Patch coverage is 74.54545% with 14 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.75%. Comparing base (4ab04e2) to head (8784246).
⚠️ Report is 4 commits behind head on main.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
...i/util/json/GsonAuditLogsDetailsActionFactory.java	74.07%	8 Missing and 6 partials ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #1636      +/-   ##
============================================
+ Coverage     73.65%   73.75%   +0.09%     
- Complexity     4675     4695      +20     
============================================
  Files           487      488       +1     
  Lines         14659    14722      +63     
  Branches       1525     1544      +19     
============================================
+ Hits          10797    10858      +61     
+ Misses         2958     2949       -9     
- Partials        904      915      +11     

Flag	Coverage Δ
jdk-14	73.75% <74.54%> (+0.09%)	⬆️

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.