revert(web-api): keep string[] for slack lists message field request input

[zimeg]

Summary

This pull request reverts #2627, restoring the Slack Lists item message field to string[] for request input.

• fix: update SlackListsItemFieldMessage to support single and array message shapes #2627 retyped the shared SlackListsItemFieldMessage.message from string[] to SlackListsItemMessage | SlackListsItemMessage[] to correct the response shape.
• That same type backs request input (SlackListsItemsCreateArguments.initial_fields and SlackListsItemCellUpdate / cells), so it broke request typing.
• Per the docs, slackLists.items.create/update message takes an array of message permalink URL strings, e.g. { "column_id": "Col123", "message": ["https://team.slack.com/archives/C123/p1234567890123456"] }.
• fix: update SlackListsItemFieldMessage to support single and array message shapes #2627 is unreleased — @slack/web-api 7.16.0, 7.17.0, and 8.0.0-rc.1 all still ship message: string[] — so this reverts the regression before it reaches a release. Its pending changeset is removed and no new changeset is added (the change nets to zero against the last release).
• The response-side object shape (fix: update SlackListsItemFieldMessage to support single and array message shapes #2627's original goal, issue SlackListsItem FieldMessage.message type does not match API response shape #2598) is intentionally deferred to codegen, which will generate per-direction request/response types and prevent this class of drift. Supersedes the still-open duplicate PRs fix(web-api): widen Slack Lists message field type #2599, Fix Slack Lists message field response types #2600, and fix(web-api): type Slack Lists message fieldFix Slack Lists message field response type responses #2621.

Note

This is a revert to stop the unreleased request-side regression. It does not fix the original response-shape issue (#2598), which is being reopened and will be addressed in a follow-up — the correct fix is to split request vs. response field types (e.g. via codegen) so both directions are typed correctly.

Testing

Gather these before running — both must come from your own workspace:

• a user ID to grant list access to (U…)
• a real message permalink (https://<team>.slack.com/archives/<C…>/p…)

With a token that has the lists:write scope, the docs-correct request shape is accepted by the API:

// Create a list with a message column.
const { list_id, list_metadata } = await client.slackLists.create({
  name: 'Message field probe',
  schema: [
    { key: 'title', name: 'Title', type: 'text', is_primary_column: true },
    { key: 'message_link', name: 'Message', type: 'message' },
  ],
});
const messageColumn = list_metadata.schema.find((c) => c.key === 'message_link');

// Grant a teammate write access (replace with a real user ID).
await client.slackLists.access.set({
  list_id,
  access_level: 'write',
  user_ids: ['U00000000'], // <-- gather before run
});

// Correct: `message` is an array of permalink URL strings — the API accepts this.
await client.slackLists.items.create({
  list_id,
  initial_fields: [
    {
      column_id: messageColumn.id,
      message: ['https://yourteam.slack.com/archives/C00000000/p0000000000000000'], // <-- gather before run
    },
  ],
});

To confirm the object shape #2627 allowed is invalid on the request side, send it untyped (the reverted types correctly reject it at compile time) and observe the API reject it too:

// Broken: `message` as a message object. Sent via apiCall to reach the API at runtime.
await client.apiCall('slackLists.items.create', {
  list_id,
  initial_fields: [
    { column_id: messageColumn.id, message: { text: 'message objects are response-only' } },
  ],
});

Observed: the correct string-array call succeeds, while the object-shape call is rejected by the API:

[ERROR]  bolt-app An API error occurred: internal_error
    at platformErrorFromResult (.../node_modules/@slack/web-api/dist/errors.js:67:33)
    at WebClient.apiCall (.../node_modules/@slack/web-api/dist/WebClient.js:232:56)
    at process.processTicksAndRejections (node:internal/process/task_queues:104:5)
    at async path/to/app.js:62:5 {
  code: 'slack_webapi_platform_error',
  data: {
    ok: false,
    error: 'internal_error',
    response_metadata: { scopes: [Array], acceptedScopes: [Array] }
  }
}

This confirms the object message shape #2627 typed for requests is invalid against the API; only the string[] permalink form is accepted.

Requirements

• I've read and understood the Contributing Guidelines and have done my best effort to follow them.
• I've read and agree to the Code of Conduct.

[changeset-bot]

⚠️ No Changeset found

Latest commit: bb390aa

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 88.90%. Comparing base (07744de) to head (bb390aa).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2640   +/-   ##
=======================================
  Coverage   88.90%   88.90%           
=======================================
  Files          63       63           
  Lines       10256    10256           
  Branches      452      452           
=======================================
  Hits         9118     9118           
  Misses       1117     1117           
  Partials       21       21           

Flag	Coverage Δ
cli-hooks	88.90% <ø> (ø)
cli-test	88.90% <ø> (ø)
logger	88.90% <ø> (ø)
oauth	88.90% <ø> (ø)
socket-mode	88.90% <ø> (ø)
web-api	88.90% <ø> (ø)
webhook	88.90% <ø> (ø)

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

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[zimeg]

@mwbrooks LGTM! I appreciate the review!