perf(calendar): serve hot releases from a single endpoint

[vladjerca]

What

Replaces the client-side "hot releases" assembly with one request to the new /calendars/releases/hot endpoint.

Before: a releases-calendar fetch plus separate trending and anticipated fetches per media type (5-6 requests), then an in-browser intersect to keep only releases that are also trending/anticipated.

After: one request. The worker does the gating and merge server-side and returns the feed already ordered by availability date. The mapper just discriminates the union response, coalesces episodes, and sorts.

Changes

• releasesCalendarQuery.ts: single api().calendars.releasesHot(...) call + discriminated mapper. Drops the HideRecommended invalidations (no recommendations in the mix anymore).
• useReleasesItems.ts / useReleasesCalendar.ts: dropped the now-dead sourceLimit.
• spec + MSW handler updated to the single-endpoint shape.
• @trakt/api bumped to 0.4.22 for the new contract.

Dependency chain

• Endpoint: trakt/trakt-workers#1181
• Contract: feat(calendars): add hot releases endpoint contract trakt-api#848 (published @trakt/api@0.4.22)

Verification

• svelte-check: 0 errors (7114 files)
• test:unit releasesCalendarQuery spec: passes
• eslint: clean

Note on filters

The merged endpoint applies one filter set to both movies and shows (matching the worker's filters() middleware), so per-type filterOverride is no longer honored here; the global filter is used. The releases surface only uses the global filter.

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request optimizes the calendar releases feature by transitioning from a multi-request client-side assembly process to a single, server-side aggregated endpoint. By offloading the filtering and merging logic to the worker, the client-side code is simplified, and the overall performance is improved by reducing the number of API calls required to populate the releases calendar.

Highlights

• Performance Optimization: Replaced multiple client-side requests for hot releases with a single call to the new /calendars/releases/hot endpoint, significantly reducing network overhead.
• Simplified Data Processing: Moved gating, merging, and sorting logic to the server-side, allowing the client to focus on mapping and coalescing the unified response.
• Dependency Update: Bumped @trakt/api to version 0.4.22 to support the new API contract.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[deepsource-io]

DeepSource Code Review

We reviewed changes in 6808dab...a1313ba on this pull request. Below is the summary for the review, and you can see the individual issues we found as inline review comments.

See full review on DeepSource ↗

PR Report Card

Overall Grade

Security   Reliability   Complexity   Hygiene   Coverage

Code Review Summary

Analyzer	Status	Updated (UTC)	Details
JavaScript		Jul 13, 2026 6:52p.m.	Review ↗
Code coverage		Jul 13, 2026 6:52p.m.	Review ↗

Code Coverage Summary

Language	Line Coverage (Overall)
Aggregate	65.3% [▼ down 0.1% from main]
Javascript	65.3% [▼ down 0.1% from main]

➟ Additional coverage metrics may have been reported. See full coverage report ↗

---

Important

AI Review is run only on demand for your team. We're only showing results of static analysis review right now. To trigger AI Review, comment @deepsourcebot review on this thread.

[gemini-code-assist]

Code Review

This pull request refactors the releases calendar query by replacing multiple API requests (upcoming movies/episodes and trending/recommended/anticipated lists) with a single call to the hot releases endpoint (/calendars/releases/hot). This simplifies the logic significantly, removing several unused helper functions, types, and the sourceLimit parameters across the calendar features. Feedback suggests adding a defensive guard on response.body in the query mapper to handle nullish or empty API responses gracefully and prevent potential runtime errors.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[vladjerca]

@gemini-code-assist Reviewed the one suggestion:

• response.body ?? [] guard: leaving as-is. defineQuery runs the mapper only after isValidResponse narrows to a 200, so the body is always the typed array; sibling calendar mappers map it raw. No runtime path where it's nullish here.

No code changes needed.

[gemini-code-assist]

Understood, thanks for the clarification. That makes sense—if isValidResponse guarantees a 200 status and the corresponding schema validation, then the body is indeed safe to treat as the typed array. I appreciate the context on the defineQuery flow.