feat(slack): derive chat.update URL from configured api_url base

[santiagofn]

Part 3 of a series implementing threaded message support for the Slack notifier. Full picture: #5150. Depends on #5239.

Summary

Moves the Slack notifier's URL resolution into a new internal package notify/slack/internal/apiurl, and routes both the initial chat.postMessage request and the chat.update request (used by update_message: true) through the same configured api_url / api_url_file base.

Behavior change

Previously the chat.update endpoint was hardcoded to https://slack.com/api/chat.update regardless of api_url. With this PR, the same base used for chat.postMessage is reused for chat.update.

• Standard configurations (api_url unset or pointing at https://slack.com/api/chat.postMessage) are unaffected: the generated URL is byte-identical to today.
• Deployments that point api_url at a Slack-API-compatible proxy or forwarder (e.g. https://my-proxy.example.com/slack/api/chat.postMessage) will now have their chat.update requests routed to the same host (https://my-proxy.example.com/slack/api/chat.update) instead of being forced back onto slack.com. For these users this is the more correct behavior, but it is a behavior change and is recorded as a `[CHANGE]` in the CHANGELOG.

Implementation

• New apiurl.Resolver captures api_url / api_url_file at notifier construction. URLForMethod("") returns the configured base URL (initial post); URLForMethod("chat.update") derives the URL by replacing the last path segment of the base, so any base path (e.g. /slack/api/chat.postMessage) is honored.
• api_url_file is read on every call, matching previous behavior so that file rotations apply to the next notification without restarting Alertmanager.
• notify/slack/slack.go now delegates both URL constructions to the resolver. The previous TestGettingSlackURLFromFile and TestTrimmingSlackURLFromFile are replaced by the resolver-level coverage in apiurl_test.go.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 332b0527-7696-4546-949c-ebd8b18f68ae

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[SoloJacobs]

It looks like this was largely AI-generated. We'd ask that contributions be reviewed and understood by the author before submitting, including making sure the commit message accurately describes what the code actually does. The message here says "refactor" but the change alters behavior. Happy to look at it again once it's been properly reviewed on your end.

[santiagofn]

It looks like this was largely AI-generated. We'd ask that contributions be reviewed and understood by the author before submitting, including making sure the commit message accurately describes what the code actually does. The message here says "refactor" but the change alters behavior. Happy to look at it again once it's been properly reviewed on your end.

hi, @SoloJacobs , sorry for the delay. one comment before all: this is still a draft, that's why i didn't share it on slack. regarding the comments, i not only reviewed but wrote code, the PR was not solely generated by AI. i chose a "refactor" label because the current behaviour was not change (the same URLs are generated in the current flow). what the PR did add was the ability of creating URLs for other methods... but they're not in use nowadays. anyways, it might be worth using a "feature" if you believe that potential use warrants it.

[SoloJacobs]

Thanks for the context. To be more precise though: The commit description says "move", which implies pure relocation.

• The chat.update URL changed from hardcoded (https://slack.com/api/chat.update) to derived from the configured base URL, which is a behavioral change for anyone using a custom api_url.
• The URL logic went from ~12 lines to 108. If this is a "move", then we is all the extra logic necessary?

So, the "refactor" part is not really the issue, you could leave it. Although, feat does seem a bit more accurate to me, since you introduce a new capability. But that is secondary