Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

chat_postMessage silently forwards thread_id to the API, so a threaded reply posts to the channel

Aberta
  • Algo errado?
#1,923 2 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 5 dias

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
48/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
python
Domínio
api, backend-api-design

Direção de pesquisa

Comece em slack_sdk/web/client.py, especialmente em chat_postMessage e files_upload_v2, e rastreie como os parâmetros declarados e **kwargs chegam a _remove_none_values e api_call. Revise as opções de aviso da issue e os testes existentes antes de escolher um comportamento. A tarefa estará concluída quando o tratamento selecionado estiver coberto para chaves desconhecidas e os casos relatados de thread_id e file_content não falharem mais silenciosamente ou de forma enganosa.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

auto-triage-skip enhancement
Summary

Every WebClient method takes **kwargs and forwards unrecognised keys into the request body
untouched. A one-character mistake in a parameter name therefore produces a request that is
missing the parameter you meant and carrying one nobody reads, with no exception and no warning.

For thread_ts nothing errors at all. A threaded reply becomes a top-level channel message and
every downstream check reports success.

Reproduction

Against slack_sdk 3.43.0, with the transport stubbed so the outgoing body is visible:

client.chat_postMessage(
    channel="C1",
    text="hi",
    thread_id="1750000000.0001",   # the parameter is thread_ts
    unfurl_link=False,             # the parameter is unfurl_links
)

Body actually sent:

{"thread_id": "1750000000.0001", "unfurl_link": false, "channel": "C1", "text": "hi"}

warnings raised: 0. thread_ts is absent from the body entirely, because it was None and
_remove_none_values stripped it. So the request is well formed, it just is not the request the
caller wrote.

Mechanism

In slack_sdk/web/client.py, chat_postMessage declares its known parameters and then does:

kwargs.update({ "channel": channel, "text": text, ..., "thread_ts": thread_ts, ... })
_parse_web_class_objects(kwargs)
kwargs = _remove_none_values(kwargs)
return self.api_call("chat.postMessage", json=kwargs)

thread_id arrived through **kwargs, survives _remove_none_values because it is not None,
and goes out with everything else. Nothing in the path compares the caller's keys against the
declared parameter list.

Why I think this deserves a fix

The declared parameters are already there, in the signature, which is what makes this cheap. The
method knows the full set of names it accepts. A caller who misses by one character is currently
told nothing at all, and the failure surfaces somewhere else, later, as a message in the wrong
place.

Three options, cheapest first:

  1. Warn on unknown keys. warnings.warn naming the key and the method. Non-breaking, and it
    makes the mistake visible in a test run.
  2. Warn harder on near misses. If an unknown key is within an edit distance of one or two of a
    declared parameter, say which one you probably meant. thread_id to thread_ts,
    unfurl_link to unfurl_links, file_content to content.
  3. Do nothing, but say so in the docstring, since the current behaviour is reasonable as an
    escape hatch for API parameters the SDK has not caught up with. That is a real design reason
    for **kwargs and I do not think it should be removed.

I would expect (1) or (2). Removing **kwargs would break the escape hatch and I am not
suggesting it.

A related one, same mechanism, different symptom

files_upload_v2(file_content=...) sends file_content through **kwargs and then raises

SlackRequestError: Any of file, content, and file_uploads must be specified.

which names three parameters the caller does not believe they omitted. Same root cause, and the
error message is actively misleading rather than merely absent.

How I found this, and what I am not claiming

I maintain a test harness that measures whether a coding model can drive a given SDK by running
the code it writes and asserting on the HTTP the SDK emits. slack_sdk 3.43.0 came out at the
top of everything I have measured: 16 tasks, 89 checks, three models at three attempts each, and
both frontier models passed all 89 checks on all 48 rollouts. So this is not a report that
models struggle with slack_sdk. They do not.

No model hit this bug. I found it by construction while checking whether my own scoring
could be gamed. That makes it latent, not measured, and I would rather say so than let it read
as a field report.

One limit on the repro above: my transport is stubbed, so what I can show is the body your SDK
sends. Whether Slack ignores thread_id and answers ok: true is your knowledge, not mine.

Happy to open a separate issue about files_upload's deprecation warning, which describes a
timeout risk ("may cause some issues like timeouts for relatively large files",
internal_utils.py:443) for an endpoint that has been sunset. Say the word rather than me
filing two at once.

toolshed is a small studio run by its owner, who directs the work, and AI does a lot of the
engineering.

Cal / toolshed / [email protected]

Linguagem predominante
Python
Estrelas
4k
Forks
861
Merge médio
3d 17h
PRs com merge (30d)
11

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de slackapi/python-slack-sdk

Todas as issues de slackapi/python-slack-sdk

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.