fix(integrations): don't trigger slack channel search on input focus#60437
Merged
Conversation
LemonInputSelect auto-fills the input with the selected option's key when single-mode is focused with a value set. The slack picker's onInputChange treated that auto-fill as a real search query, sending the composite "id|#name" string to the server. The backend returns no matches for it, the loader overwrites the cached channel list with [], and after blur the picker can no longer resolve the bare ID to a name — only the channel ID ends up displayed. Skip the server-side search when val matches the currently displayed key (modifiedValue). Real user typing still differs and still triggers a fetch, so search behavior is preserved.
Contributor
|
Size Change: 0 B Total Size: 80.6 MB ℹ️ View Unchanged
|
Contributor
|
🎭 Playwright report · View test results →
These issues are not necessarily caused by your changes. |
Adds a SlackChannelPicker component test that renders the picker with an existing composite "id|#name" value, waits for the initial channel load, focuses the input, and asserts no additional GET /channels?search=<composite> fires. Without the val !== modifiedValue guard the second request happens, returns no matches, and wipes the cached channel list — which is the visible regression in the screenshots shared after #60267 merged. A second test covers the still-works path where typing a real different query correctly triggers the server-side search.
The "does not search for the composite key" assertion waited 400ms after focus — only ~50-100ms over the 300ms kea-loaders breakpoint plus fetch round-trip. A slow CI runner could easily observe the channelsRequestSearchQueries array before the unwanted second request lands, producing a silent false negative where a regression looks like a pass. Bump the wait to 1s and the type-fires-search timeout to 5s.
Contributor
|
Reviews (1): Last reviewed commit: "test(integrations): widen timing budget ..." | Re-trigger Greptile |
meikelmosby
approved these changes
May 28, 2026
This was referenced May 28, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Follow-up regression from #60267. When a destination's Slack channel picker is opened with a value already set and the user clicks into the input, the picker can lose name resolution after blur — only the bare channel ID ends up displayed.
The cause is in
SlackChannelPicker.onInputChange.LemonInputSelect._onFocus(seefrontend/src/lib/lemon-ui/LemonInputSelect/LemonInputSelect.tsx:529-533) auto-fills the input with the selected option's key ("C0B6HUH9FUH|#test-slack-notifications") when single-mode is focused with a value set, which firesonInputChange(compositeKey). After #60267 that path falls through toloadAllSlackChannels(false, compositeKey), sending the composite string as a search query. The backend returns no matches for it, the loader overwrites the cached channel list with[], and after blur the bare ID can no longer resolve to a#name (ID)label.A related fix already on master routes ID-shaped input (
/^[CGD][A-Z0-9]{8,}$/) to a direct lookup, but the composite key with|#falls through to the search branch and still wipes the cache.Changes
frontend/src/lib/integrations/SlackIntegrationHelpers.tsx: inonInputChange, skip the server-side search whenvalmatches the currently displayedmodifiedValue. Real user typing produces a differentvaland still triggers a fetch, so search behavior is preserved.How did you test this code?
Agent-authored — no manual browser testing. The existing
slackIntegrationLogic.test.tssuite (6 tests including the search-then-clear regression test) still passes. The fix lives in the component'sonInputChange, which isn't covered by a component-level test today; happy to add one if you want, but I'd want to set up the picker test harness as its own follow-up.Publish to changelog?
no
🤖 Agent context
Authored by Claude Code (claude-opus-4-7) after the user reported the regression on the merged PR with screenshots showing the bare-ID display state after click-in/click-away. The fix combines the master-side ID-pattern routing with the new
val !== modifiedValueguard, so:val !== modifiedValue→ search (preserved)val === modifiedValue→ no-op (the new guard)Generated by Claude Code