Skip to content

fix(google_chat): report why a send failed - #6748

Open
purisev wants to merge 2 commits into
keephq:mainfrom
purisev:fix/google-chat-error-reporting
Open

fix(google_chat): report why a send failed#6748
purisev wants to merge 2 commits into
keephq:mainfrom
purisev:fix/google-chat-error-reporting

Conversation

@purisev

@purisev purisev commented Sep 2, 2026

Copy link
Copy Markdown

Problem

See #6746. __send_message inside GoogleChatProvider._notify returns only on 200
and raises otherwise, so the response.status_code != http.HTTPStatus.OK check
after the call can never fire and the ProviderException under it, the one
carrying response.text, is unreachable. A rejected message surfaces as
Failed to notify message after 3 attempts with Google's explanation discarded,
so a malformed payload and a revoked key look the same from the workflow.

Fix

  • The dead check is gone, and the last error from the retry loop — status code
    plus response body, or the connection error — now travels with the exception.
  • Errors are redacted on the way out. Google quotes the request URL in some of
    its errors, and a Chat webhook URL carries key and token in its query
    string. The connection errors already being logged went out with the URL
    intact; they go through the same redaction now.

Behaviour on success is unchanged.

Tests

The retry loop had no coverage at all, which is what hid this.
tests/providers/google_chat_provider/test_google_chat_provider.py is new and
covers one attempt on success, a transient failure retried and then succeeding,
three attempts before giving up, the body reaching the caller, redaction of both
a response body and a connection error, the content type header, and unrelated
workflow parameters being ignored. 8 tests, all passing.

Fixes #6746

__send_message returns only on 200 and raises otherwise, so the
`response.status_code != OK` check after the call could never fire and the
ProviderException under it, the one carrying response.text, was unreachable.
A rejected message surfaced as "Failed to notify message after 3 attempts"
with the reason discarded, so a malformed payload and a revoked key looked
the same from the workflow.

That check is gone and the last error, response body included, now travels
with the exception. It is redacted on the way: Google quotes the request URL
in some of its errors and that URL carries the key and token credentials in
its query string. Connection errors were already being logged with the URL
intact and go through the same redaction now.

The retry loop had no coverage at all, which is what hid this. The tests
cover one attempt on success, a transient failure retried and then
succeeding, three attempts before giving up, the body reaching the caller,
redaction of both a response body and a connection error, the content type
header, and unrelated workflow parameters being ignored.

Signed-off-by: Iurii Purisev <92510590+purisev@users.noreply.github.com>
@CLAassistant

CLAassistant commented Sep 2, 2026

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[🐛 Bug]: Google Chat provider hides the reason a send failed

2 participants