gabotorresruiz commented on PR #35832:
URL: https://github.com/apache/superset/pull/35832#issuecomment-3555086684
Hey @Vitor-Avila, thanks for the thorough review! Let me address your
concerns:
## Rate Limits Concern
Your concern about "more API calls from typing" is valid but largely
mitigated by the caching architecture:
**With cache warm (normal operation):**
- All user requests hit cache --> **0 API calls**
- In-memory filtering for searches --> instant results
- No rate limit risk during normal usage
**API calls only happen:**
- During initial cache warmup (once, in background)
- When user clicks "Refresh channels" button
- When cache expires (configurable TTL via `SLACK_CACHE_TIMEOUT`)
So the typing scenario you described (each keystroke = new API call)
**doesn't happen** when cache is available. The cache stores all channels and
filtering happens entirely in-memory
## How Search Works
Since Slack's `conversations.list` API doesn't support server-side
filtering, I've implemented search "client-side":
**Cache path (normal operation):**
1. All channels are pre-fetched and stored in cache
2. When a user types some text to search a channel, this gets filtered
in-memory against cached
3. Results returned instantly with no Slack API calls
**Search features:**
- **Partial matching**: "eng" matches "engineering-team", "frontend-eng",
etc.
- **Comma-separated OR logic**: "engineering,marketing" matches channels
containing either term
- **Matches both name and ID**: Search works on channel names and Slack
channel IDs
- **Pagination**: Large result sets are paginated with synthetic cursors
for cache data
## Cache Architecture
The implementation uses a background Celery task to warm the cache:
1. **Background warmup**: `cache_channels` task fetches all channels with
pagination, respecting rate limits via `RateLimitErrorRetryHandler`
2. **Complete cache**: Stores ALL channels (no arbitrary limit)
3. **Configurable retry**: `SLACK_API_RATE_LIMIT_RETRY_COUNT` controls retry
behavior for rate limits
## Non-Blocking Cache Warmup
The cache warmup is designed to never block the UI or degrade user
experience:
**Asynchronous execution:**
- Cache warmup runs as a **Celery background task** in a separate worker
process
- The API endpoint returns immediately after triggering the task
- UI shows a brief "refreshing" state but remains fully interactive
**User experience flow:**
1. User clicks "Refresh channels" button
2. API clears cache and triggers `cache_channels.delay()` (async)
3. API returns immediately --> UI updates instantly
4. Celery worker fetches channels in background (can take minutes for
large workspaces)
5. Next user request sees the newly warmed cache
**Cold cache behavior:**
- If cache is empty, the first request fetches one page from API (up to
999 channels)
- User sees immediate results while background task continues warming
- Subsequent requests benefit from progressively warmer cache
**No hanging or timeouts:**
- Individual API requests have reasonable timeouts
- Long-running warmup happens entirely in background worker
## How This PR Relates to https://github.com/apache/superset/pull/35622:
They're **complementary**, not alternatives:
- **#35622:** Better retry handling WHEN rate limits occur
- **This PR:** Reduce API calls to PREVENT rate limits via caching
https://github.com/apache/superset/pull/35622 helps us recover from rate
limits; this PR helps avoid them entirely
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
