Fetch feed own capabilities on activity added #154
Conversation
PR checklist ✅All required conditions are satisfied:
🎉 Great job! This PR is ready for review. |
SDK Size Comparison 📏
|
There was a problem hiding this comment.
Pull request overview
This PR implements fetching feed own capabilities on ActivityAdded events when the capabilities aren't already cached. The backend sends empty own_capabilities in activities from WebSocket events, so this change introduces a batched API endpoint to fetch them on-demand when needed.
Key Changes:
- Introduced
FeedsCapabilityRepositorywith batching and caching to efficiently fetch and store feed capabilities - Created
StateEventEnricherto enrichActivityAddedevents with cached capabilities or trigger fetch requests - Added
FeedCapabilitiesUpdatedstate event to propagate capability updates across the system - Extended
ActivityData.update()to preserve feed capabilities like other "own" properties (bookmarks, reactions, poll votes)
Reviewed changes
Copilot reviewed 27 out of 27 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
FeedsCapabilityRepository.kt |
New repository implementing batched fetching, caching, and distribution of feed capabilities with exponential retry logic |
StateEventEnricher.kt |
New enricher that intercepts ActivityAdded events to populate capabilities from cache or trigger fetch requests |
StateUpdateEvent.kt |
Added FeedCapabilitiesUpdated event to notify listeners when capabilities are cached |
FeedEventHandler.kt |
Added handler for FeedCapabilitiesUpdated events in feed state |
ActivityListEventHandler.kt |
Added handler for FeedCapabilitiesUpdated events in activity list state |
FeedStateImpl.kt |
Implemented onFeedCapabilitiesUpdated() to update capabilities in activities matching the updated feed IDs |
ActivityListStateImpl.kt |
Implemented onFeedCapabilitiesUpdated() to update capabilities in activities with matching feeds |
FeedListImpl.kt |
Added capability caching when querying feeds |
FeedImpl.kt |
Added capability caching on feed getOrCreate |
ActivityListImpl.kt |
Added capability caching when querying activities |
ActivityImpl.kt |
Added capability caching when fetching individual activities |
ActivityOperations.kt |
Extended ActivityData.update() to preserve currentFeed capabilities; added updateFeedCapabilities() helper |
FeedsClientImpl.kt |
Integrated StateEventEnricher into event processing pipeline; added repository and enricher dependencies |
Create.kt |
Instantiated FeedsCapabilityRepository with batcher and StateEventEnricher; refactored subscription manager creation |
*Test.kt files |
Comprehensive test coverage for new repository, enricher, event handlers, and state updates |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.
...in/kotlin/io/getstream/feeds/android/client/internal/repository/FeedsCapabilityRepository.kt
Outdated
Show resolved
Hide resolved
...otlin/io/getstream/feeds/android/client/internal/repository/FeedsCapabilityRepositoryTest.kt
Show resolved
Hide resolved
|
| ownBookmarks = ownBookmarks, | ||
| ownReactions = ownReactions, | ||
| poll = updated.poll?.let { poll?.update(it) ?: it }, | ||
| currentFeed = updated.currentFeed?.let { currentFeed?.update(it) ?: it }, |
There was a problem hiding this comment.
Should we fallback to this.currentFeed if updated.currentFeed == null? Otherwise we could end up overriding the this.currentFeed if the updated one is null?
| import java.util.concurrent.ConcurrentHashMap | ||
| import kotlinx.coroutines.CoroutineScope | ||
|
|
||
| internal class FeedsCapabilityRepository( |
There was a problem hiding this comment.
Can we rework this a bit so that we have an interface FeedsCapabilityRepository and a concrete implementation class FeedsCapabilityRepository to keep it aligned with the other repository definition?
| val activity = | ||
| activitiesRepository.getActivity(activityId).onSuccess { | ||
| subscriptionManager.onEvent(StateUpdateEvent.ActivityUpdated(FidScope.unknown, it)) | ||
| it.currentFeed?.let(capabilityRepository::cache) |
There was a problem hiding this comment.
Is it a valid scenario that we get updated ownCapabilities for the same feed?
I am thinking something along the way of:
- We do
activity.get()-> get one set ofownCapabilities - We do
activityList.get()-> get a different set ofownCapabilitiesfor the samefeed
Wouldn't the activity from step one now reference the old capabilities set? I am thinking if we should maybe introduce FeedCapabilitiesUpdated handling for the Activity object as well 🤔
Goal
AND-818
Backend sends empty
own_capabilitiesin the feed in activities on the activity added event (like for other "own" properties). So they added an endpoint to fetch them if we don't have them cached locally (e.g. we can cache them iffeed.getOrCreate()was called because they're returned there).Implementation
FeedsCapabilityRepositoryto handle caching and fetching capabilitiesStateEventEnricherto use the repository'sgetOrRequestto enrichActivityAddedor request capabilities to be fetchedFeedCapabilitiesUpdatedstate event to notify on capabilities cached & handle it where needed (i.e. where we also handleActivityAdded)ActivityData.updateto preserve feed capabilities like otherownpropertiesTesting
Checklist