Cutoff Date

Some activity selectors have no cutoff by default and scan your feed's entire history on every read. That's fine in development, but with a filter on a large production dataset it becomes a performance risk.

Without a filter, the newest activities are usually enough and the read is fast. Add a filter with no cutoff and the search has no time bound: a selective filter (few or no recent matches) can scan huge amounts of history and time out with a 500, often only after launch once data has grown. A cutoff_window bounds the scan, so a selective filter returns "nothing in the window" quickly.

Rule of thumb: if a selector uses a filter that runs at read time, set a cutoff_window.

Which selectors need this

current_feed supports richer filters (search_data, text, near) that force read-time computation: the path a cutoff protects.

How to set a cutoff

Set cutoff_window on the selector: a relative duration ("the last N ..."). Units: s, m, h, d, w, y (for example "12h", "7d", "2w"); minimum 1 hour.

// Bound a filtered current_feed scan to the last 14 days.
var response = await _feedsV3Client.CreateFeedGroupAsync(new CreateFeedGroupRequest
{
    ID = "team_updates",
    ActivitySelectors = new List<ActivitySelectorConfig>
    {
        new()
        {
            Type = "current_feed",
            Filter = new Dictionary<string, object>
            {
                ["search_data"] = new Dictionary<string, object>
                {
                    ["$contains"] = new Dictionary<string, object>
                    {
                        ["category"] = "announcement"
                    }
                }
            },
            CutoffWindow = "14d"
        }
    }
});

Choosing a window

• Match scroll depth: 7d to 14d suits most hot feeds; keep older content in search or an archive.
• Narrower filters need shorter windows.
• Start conservative, widen later if needed.