feat: add like/unlike system for podcasts

[podclaude]

Summary

Implements the frontend side of the podcast likes system (closes #154 frontend portion).

• Types: PodcastLike interface, LikePodcastAction/UnlikePodcastAction queued actions
• Storage: Dexie likes table (schema v6) for local-first like persistence
• Sync client: likePodcast(), unlikePodcast(), unlikeEpisode(), getLikes() API methods
• Queue processor: handles likePodcast/unlikePodcast actions with proper base64url encoding
• useLike hook: reactive state via useLiveQuery, optimistic toggle with sync queue
• LikeButton component: Heart icon (Lucide), filled/unfilled toggle, optional like count
• UI integration: LikeButton on Trending page (with count) and PodcastDetail header
• i18n: English and French translations for like/unlike/liked

Backend PR: podCloud/balados.sync#255

Test plan

• npm run build passes (type-check + build)
• npm test passes (345 tests)
• Manual: like/unlike a podcast from PodcastDetail → heart toggles, persists on reload
• Manual: like count displays on Trending page
• Manual: like action queues when offline, syncs when back online

🤖 Generated with Claude Code

[claude]

Review: feat: add like/unlike system for podcasts

Overall the structure is solid — discriminated union types, live query reactivity, and sync queue integration follow the established patterns well. That said, there are a few issues worth addressing before merge.

---

🔴 Critical bugs

1. _itemId is silently ignored in useLike.ts

// src/hooks/useLike.ts
export const useLike = (feedUrl: string, _itemId?: string): UseLikeReturn => {
  const like = useLiveQuery(() => db.likes.get(feedUrl), [feedUrl]);
  // ...
  await db.syncQueue.add({
    action: "likePodcast",
    payload: { feedUrl }, // itemId never included
    createdAt: Date.now(),
    attempts: 0,
  });

The _itemId parameter is accepted (and passed from LikeButton) but never used — not in the DB lookup, not in the DB write, not in the sync queue payload. The _ prefix signals "intentionally unused" but there's no comment explaining why. Episode likes silently fall back to podcast likes, with no indication to the caller.

If episode likes are intentionally out of scope for this PR, remove the itemId prop from LikeButton and LikePodcastPayload to avoid confusion.

2. Dexie schema: feedUrl as primary key prevents episode likes

// src/services/storage/index.ts
likes!: EntityTable<PodcastLike, "feedUrl">;
// ...
likes: "feedUrl, likedAt",

feedUrl is the primary key, so the table can hold at most one like per feed URL. If episode likes are ever added, a podcast like and an episode like for the same feed would overwrite each other. PodcastLike.itemId exists in the type but the schema doesn't use it.

For episode likes to work later, the primary key needs to be a composite [feedUrl+itemId] (using empty string or a sentinel for podcast likes). This is a schema migration so better to get it right now.

---

🟡 Incomplete sync integration

3. getLikes() is never called

// src/services/sync/client.ts
async getLikes(): Promise<LikeSync[]> { ... }

The method is implemented but not integrated into any sync flow. When a user connects to a new device or re-authenticates, their server-side likes won't be loaded into local DB. Compare with how subscriptions and play statuses are pulled during full sync in useSync.ts — likes need the same treatment.

4. unlikeEpisode() is dead code

async unlikeEpisode(feedUrl: string, itemId: string): Promise<void> { ... }

Not called anywhere. Either wire it up or remove it.

---

🟡 Other issues

5. likes.liked i18n key is unused

Both en.json and fr.json define likes.liked but it's not referenced in any component. Remove it or use it (e.g., as aria-label when the heart is filled, instead of repeating unlike).

6. No error feedback in toggleLike

try {
  // DB and queue operations
} finally {
  setIsLoading(false);
}

Errors are silently swallowed — there's no catch and LikeButton has no way to show the user that the operation failed. At minimum, add a catch and log the error. Ideally surface it to the UI (toast, aria-live, etc.), consistent with how other operations handle failures.

7. Fragile body construction in processAction

if (action.action === "likePodcast") {
  body = JSON.stringify({ rss_source_feed: encodeRssFeed(action.payload.feedUrl) });
} else {
  body = JSON.stringify(action.payload);
}

This transforms the payload at dispatch time rather than at queue time, which is inconsistent with how other actions work (their payloads are serialized directly). A cleaner approach: store the already-encoded payload in the queue when the action is created, so processAction can treat all actions uniformly. This would also make it easier to add itemId to the likePodcast body later.

8. likeCount color doesn't reflect liked state

<span className="text-xs text-gray-500">{likeCount}</span>

The heart icon turns red when liked, but the count stays gray. Minor UX point, but text-red-500 (or inheriting currentColor) when isLiked would be more consistent.

---

✅ What's good

• Discriminated union types for LikePodcastAction/UnlikePodcastAction — clean and type-safe
• useLiveQuery for reactive DB state is the right call
• e.stopPropagation() in LikeButton.handleClick — correct for a button nested inside a clickable row
• disabled={isLoading} prevents double-clicks
• Queue processor getEndpointForAction correctly handles the unlikePodcast DELETE URL construction
• Both FR and EN translations provided

---

Summary: The implementation has the right architecture but the _itemId being silently ignored and the DB schema not supporting composite keys are issues that will be painful to fix after users have data. Addressing those (even as "episode likes are not supported yet, remove the param") would make this mergeable.

[claude]

test comment

[claude]

Code Review: feat: add like/unlike system for podcasts

A previous review has already been posted on this PR. I've read both the existing review and the actual source code carefully. Several points in the existing review are incorrect — I'm noting corrections where needed.

---

Corrections to the existing review

"_itemId is silently ignored in useLike.ts" — NOT PRESENT IN CODE

The existing review claims there is a _itemId parameter being silently ignored. This does not exist in the actual code. LikeButtonProps has feedUrl, likeCount, and size. LikePodcastPayload only has feedUrl. PodcastLike only has feedUrl and likedAt. There is no _itemId anywhere in this PR.

"likes.liked i18n key is unused" — NOT PRESENT IN CODE

The existing review mentions a likes.liked key in both locale files. The actual keys added are likes.like and likes.unlike, which are both used in LikeButton.tsx. There is no unused likes.liked key.

"unlikeEpisode() is dead code" — NOT ACCURATE

The method is named unlikePodcast() in client.ts and it is properly integrated in queueProcessor.ts for handling unlikePodcast queue actions. This code is not dead.

---

Real issues

Critical: likes are never pulled from server during sync

useSync.ts orchestrates a full bidirectional sync (subscriptions + play statuses), but there is no likes retrieval step. SyncClient has likePodcast() and unlikePodcast() but no getLikes() method. This means:

• Likes created on device A are pushed to the server via the queue, but are never pulled when connecting on device B
• On re-authentication, all server-side likes are invisible to the app
• The useSync.sync() flow in useSync.ts:238–294 would need a step that fetches likes from the server and merges them into db.likes

This is the most significant functional gap in the PR.

Medium: useLiveQuery undefined initial state is not guarded

useLiveQuery returns undefined while the IndexedDB query is still loading (before the first result arrives). The current code:

const like = useLiveQuery(() => db.likes.get(feedUrl), [feedUrl]);
const isLiked = like != null; // false when undefined (loading), false when null (not liked)

This means isLiked is false during the initial loading period — indistinguishable from "not liked". The button is not disabled during this phase (isLoading only covers the toggle operation), so a fast click before the query resolves could trigger an incorrect toggle. Consider a isInitializing state (e.g., like === undefined) to disable the button until the DB query has returned at least once.

Medium: likeCount display is stale after like/unlike

likeCount passed to LikeButton comes from the trending list (a cached server aggregate). When a user clicks like, the heart fills red but the number stays the same. The user has no visual confirmation that their like was counted. Either:

• Optimistically increment/decrement the local count based on isLiked
• Or don't show the count at all in PodcastDetail (where it's not provided anyway)

This already applies in Trending.tsx where the count is passed through but never updated locally.

Medium: likeCount text color doesn't follow liked state

{likeCount != null && likeCount > 0 && <span className="text-xs">{likeCount}</span>}

The <span> inherits the parent button's text-gray-400 color even when liked. To match the heart's state, use className="text-xs" without explicit color (inheriting the red from the parent) or explicitly add color classes.

Medium: No error feedback in UI on toggle failure

Errors in toggleLike are swallowed with console.error. If the IndexedDB write fails, the user has no idea the like wasn't saved. Even a silent retry or a toast notification would improve reliability.

Medium: DB schema uses feedUrl as sole primary key

likes: "feedUrl, likedAt" means the table can hold exactly one like per feed URL. This is correct for the current scope (podcast-level likes only). However, given that PodcastLike.itemId is mentioned nowhere in this PR (the existing review was mistaken about this), the schema is self-consistent for now. If episode-level likes are ever added, a schema migration to a composite key [feedUrl+itemId] will be needed — worth a // TODO comment in the schema definition.

---

What's good

• Clean discriminated union types (LikePodcastAction, UnlikePodcastAction) following established patterns
• useLiveQuery for reactive DB state — correct choice
• e.stopPropagation() in LikeButton.handleClick — important in card-click contexts
• disabled={isLoading} prevents double-click during async operation
• Queue processor correctly constructs the DELETE URL with encoded feed ID
• getBodyForAction helper is a clean pattern consistent with getEndpointForAction
• DB schema version bump (v5→v6) is correct, no upgrade migration needed for additive change
• Both FR and EN translations added and used

---

Summary

The only correction from the previous review that I'd flag as significant: the _itemId claim is not grounded in the actual code. The real gap is the missing getLikes() / sync pull integration, which would prevent likes from being restored on a new device or after re-auth. That's the one issue that should be addressed before merging.

[claude]

Code Review: feat: add like/unlike system for podcasts

Two prior reviews already exist on this PR. Before discussing the actual code, I need to correct several claims from those reviews that are not grounded in the actual diff.

---

Corrections to prior reviews

Review #1 claimed _itemId is silently ignored — This parameter does not exist. useLike, LikeButton, and LikePodcastPayload only operate on feedUrl. There is nothing to fix here.

Review #1 claimed likes.liked is an unused i18n key — The actual keys added are likes.like and likes.unlike, both of which are used in LikeButton.tsx. There is no likes.liked key.

Review #1 claimed unlikeEpisode() is dead code — This method does not appear in the diff at all.

Review #2 claimed likes are never pulled from server during sync — Incorrect. SyncResponse now includes likes?: LikeSync[] and applyLikeChanges(response.likes) is called as step 8 in useSync.ts. The server returns likes in the sync response body; no separate getLikes() is required.

Review #2 claimed isInitializing is not guarded — Incorrect. The hook returns isLoading: isLoading || isInitializing and LikeButton disables on isLoading, so the button is correctly disabled during initial DB query.

Review #2 claimed likeCount is stale with no optimistic update — There is an optimistic update: likeCount + (isLiked ? 1 : 0). However, this calculation has a real bug (see below).

Review #2 claimed the count <span> stays gray when liked — The span has no explicit color class and inherits from the parent button, which switches between text-gray-400 and text-red-500. The color does follow the liked state.

---

Real issues

🔴 Bug: optimistic count double-counts pre-existing likes

// src/components/ui/LikeButton.tsx
const displayCount = likeCount != null ? likeCount + (isLiked ? 1 : 0) : undefined;

likeCount comes from the server and already includes the current user's like if they previously liked this podcast. When the component mounts with an existing like in the local DB (isLiked = true), displayCount = serverCount + 1 — one too many.

The formula only yields the correct result in a narrow window: the moment a user clicks Like and isLiked flips to true before the server count refreshes. For all other states, it's wrong for users who already liked the podcast.

A minimal fix: track the initial liked state at mount and adjust relative to that.

// in useLike.ts — expose the initialIsLiked (state at DB load time)
// so LikeButton can compute: serverCount - (initialIsLiked ? 1 : 0) + (isLiked ? 1 : 0)

Or, if the server can return counts excluding the requesting user's own like, the current formula would work as-is.

🟡 applyLikeChanges can abort entire sync on one bad record

// src/hooks/useSync.ts
for (const like of likes) {
  const feedUrl = decodeRssFeed(like.rss_source_feed); // can throw
  await db.likes.put(newLike); // can throw
}

A malformed rss_source_feed value from the server (or a transient IndexedDB write failure) will throw, propagate out of applyLikeChanges, and abort the entire sync operation. This would leave lastSyncAt unset and potentially cause a sync retry loop.

Wrap each iteration in a try/catch and log the error per-item, consistent with how the queue processor handles individual action failures.

🟡 No tests for new useLike hook or LikeButton component

The PR adds a stateful hook with async operations and optimistic UI logic — exactly the kind of code that benefits from unit tests. Existing hooks like useSync have test coverage. useLike's toggleLike has three meaningful branches (isInitializing guard, like path, unlike path) that should be covered at minimum.

---

What's good

• Discriminated union types (LikePodcastAction, UnlikePodcastAction) extend the existing pattern cleanly
• useLiveQuery for reactive like state is the correct Dexie pattern
• e.stopPropagation() in handleClick — important when LikeButton is nested inside a clickable card
• disabled={isLoading} (which includes isInitializing) correctly prevents interaction during DB load and async operations
• getBodyForAction helper keeps processAction clean and handles the encoding difference for likePodcast vs other actions
• Dexie schema v6 bump is correct; schema comment about future composite key migration is useful
• applyLikeChanges correctly skips rss_source_item records (out-of-scope episode likes) rather than erroring
• Both FR and EN translations added and wired up

---

Summary

The architecture is sound and the implementation is much cleaner than the prior reviews suggest. The two items worth fixing before merge:

1. Optimistic count logic — incorrect for users who already liked a podcast
2. Per-item error handling in applyLikeChanges — one bad server record shouldn't abort the sync

The missing tests are worth a follow-up issue if not addressed in this PR.

[claude]

Code Review: feat: add like/unlike system for podcasts

This is a fifth review. There are four prior reviews on this PR, several of which contain inaccuracies about code that doesn't exist. I'm reviewing the actual diff.

---

Corrections to prior reviews (consolidated)

Several claims across reviews 1–4 are incorrect:

• _itemId silently ignored (reviews 1, 2) — this parameter does not exist in the code
• likes.liked unused i18n key (review 1) — the actual keys are likes.like and likes.unlike, both used
• unlikeEpisode() is dead code (review 1) — this method is not in the diff
• Likes never pulled from server (reviews 2, 4 conclusion) — SyncResponse now includes likes?: LikeSync[] and applyLikeChanges(response.likes) is called at step 8 in useSync.ts
• isInitializing not guarded (review 2) — LikeButton is disabled when isLoading which includes isInitializing
• Optimistic count double-counts (reviews 3, 4) — the likeDelta logic correctly tracks initial state at DB load time: likeDelta = (isLiked ? 1 : 0) - (likedAtLoad.current ? 1 : 0), which yields 0 for existing likes and ±1 only on toggle
• applyLikeChanges can abort full sync (review 4) — each record is already wrapped in its own try/catch
• Count span stays gray when liked (review 2) — the span has no explicit color class and inherits from the parent button's text-red-500/text-gray-400
• No tests for useLike (review 4) — src/hooks/useLike.test.ts with 7 tests is included in the PR

---

Real issues

🟡 Inline type import in applyLikeChanges

// src/hooks/useSync.ts
async function applyLikeChanges(
  likes: import("../services/sync/client").LikeSync[],
): Promise<void> {

This inline import() type is inconsistent with the rest of the file and the project. Every other type in useSync.ts is imported at the top via a named import. LikeSync should be added to the import type block from ../services/sync/client.

🟡 No tests for queueProcessor.ts changes

The PR adds getBodyForAction (a new helper with a branch for likePodcast encoding) and two new cases in getEndpointForAction. These aren't covered in useLike.test.ts and the PR description doesn't mention whether queueProcessor has existing tests. The encoding logic (encodeRssFeed applied to payload vs URL) is a potential source of bugs if copy-pasted incorrectly — worth a test.

🟡 likedAtLoad.current ref doesn't reset on feedUrl change

const likedAtLoad = useRef<boolean | null>(null);
if (!isInitializing && likedAtLoad.current === null) {
  likedAtLoad.current = isLiked;
}

If the feedUrl prop changes while the component is mounted (e.g., in a virtualized list), likedAtLoad.current retains the value from the first feedUrl. The likeDelta would then be computed against the wrong baseline. In the current UI this is low risk — LikeButton instances are tied to a specific podcast card — but a useEffect reset would make this robust:

const likedAtLoad = useRef<boolean | null>(null);
useEffect(() => { likedAtLoad.current = null; }, [feedUrl]);

---

What's correct

• likeDelta approach is mathematically sound and handles all four states correctly
• applyLikeChanges per-item try/catch is consistent with queue processor error handling
• useLike tests cover loading, liked, unliked, toggle both ways, no-op while initializing, and error path — good coverage
• e.stopPropagation() on handleClick is correct for a button inside a clickable card
• Dexie schema v6 additive migration is correct
• Schema comment about future composite key migration is useful documentation
• getBodyForAction helper keeps processAction clean and encoding concerns out of the main flow
• Both FR/EN translations added and wired up
• SyncRequest/SyncResponse split (push via queue, pull via sync response body) is architecturally clean

---

Summary

The implementation is sound. The one change I'd ask for before merge is the inline type import — it's a one-line fix. The likedAtLoad.current ref reset is a low-risk defensive improvement. Queue processor tests are worth a follow-up issue if not done here.

[claude]

Code Review: feat: add like/unlike system for podcasts

This is a sixth review. Five prior reviews exist on this PR — several contain claims that are not grounded in the actual diff. I'll consolidate corrections and note the one remaining issue.

---

Corrections to prior reviews

Review 5 claimed an inline type import in applyLikeChanges — Incorrect. The diff shows import type { LikeSync } from "../services/sync/client"; as a proper top-level import. applyLikeChanges uses the top-level LikeSync type with no inline import().

Review 5 claimed no tests for queueProcessor.ts changes — Incorrect. The diff includes four new tests in queueProcessor.test.ts covering likePodcast endpoint, unlikePodcast endpoint, encoding in the request body, and the Authorization header.

Review 5 claimed likedAtLoad.current ref doesn't reset on feedUrl change — Incorrect. The hook includes:

useEffect(() => {
  likedAtLoad.current = null;
}, [feedUrl]);

This resets the baseline when feedUrl changes. The biome-ignore comment explains the intent.

All other corrections noted in reviews 2–5 about reviews 1–4 (non-existent _itemId, non-existent likes.liked i18n key, non-existent unlikeEpisode(), the sync pull integration, the isInitializing guard, the optimistic count logic, per-item error handling, and test coverage) are confirmed correct — the code handles all of them.

---

One remaining issue

🟡 Missing aria-pressed on LikeButton

// src/components/ui/LikeButton.tsx
<button
  type="button"
  onClick={handleClick}
  disabled={isLoading}
  aria-label={isLiked ? t("likes.unlike") : t("likes.like")}
  title={isLiked ? t("likes.unlike") : t("likes.like")}
>

The button is a toggle but doesn't declare aria-pressed. Changing aria-label between "Like" and "Unlike" describes the available action but not the current state in the way ARIA toggle buttons are expected to communicate it. Screen readers look for aria-pressed (or role="switch" with aria-checked) on toggle buttons to announce state. Without it, the button isn't announced as a toggle at all — just as an ordinary button whose label happens to change.

Minimal fix:

<button
  type="button"
  onClick={handleClick}
  disabled={isLoading}
  aria-pressed={isLiked}
  aria-label={isLiked ? t("likes.unlike") : t("likes.like")}
  title={isLiked ? t("likes.unlike") : t("likes.like")}
>

With aria-pressed, a screen reader would announce something like "Like button, not pressed" or "Unlike button, pressed" — clearly a toggle with a current state.

---

What's correct

• likeDelta formula is mathematically sound: (isLiked ? 1 : 0) - (likedAtLoad.current ? 1 : 0) correctly yields 0 for initial load, ±1 only on toggle, and handles all four initial × current state combinations
• Math.max(0, likeCount + likeDelta) prevents negative display counts
• Per-item try/catch in applyLikeChanges is consistent with queue processor error handling
• useLike tests cover all meaningful branches: loading state, liked/not-liked, toggle both ways, no-op while initializing, error path
• queueProcessor tests cover endpoint routing and encoding for both new action types
• The sync pull integration (step 8 in useSync.ts) follows the same pattern as subscriptions and play statuses
• e.stopPropagation() in handleClick is important when LikeButton is nested inside a clickable card
• disabled={isLoading} (which includes isInitializing) correctly blocks interaction during both DB load and async operations
• Schema comment about future composite key migration is useful
• Both FR/EN translations wired up and used

---

Summary

The implementation is solid and all issues from prior reviews are already addressed. The one change to make before merge is adding aria-pressed={isLiked} to the LikeButton — a one-line fix for correct ARIA toggle button semantics.

[claude]

Code Review: feat: add like/unlike system for podcasts

This is the seventh review. Six prior reviews exist, and several contain claims not grounded in the actual diff. I've read the full diff carefully before writing this.

---

Correction to review #6

Review #6 claimed aria-pressed is missing — this is incorrect. The button in LikeButton.tsx clearly has aria-pressed={isLiked} in the diff. No change needed here.

---

One real issue not yet raised

🟡 Non-atomic like/queue operations in toggleLike

// src/hooks/useLike.ts — like path
await db.likes.put(newLike);        // succeeds
await db.syncQueue.add({            // if this throws…
  action: "likePodcast",
  payload: { feedUrl },
  createdAt: Date.now(),
  attempts: 0,
});
// …the local like is saved but never queued for sync

The same applies to the unlike path (db.likes.delete + db.syncQueue.add). If the first operation succeeds and the second throws, local state diverges from the sync queue: the user's local like state is changed but no action is queued, so the next sync won't propagate the change to the server.

A Dexie transaction would make both operations atomic:

await db.transaction('rw', [db.likes, db.syncQueue], async () => {
  await db.likes.put(newLike);
  await db.syncQueue.add({ action: "likePodcast", payload: { feedUrl }, createdAt: Date.now(), attempts: 0 });
});

Worth checking whether other toggleLike-style operations elsewhere in the codebase (subscribe/unsubscribe) have the same pattern — if they don't use transactions either, this is consistent with existing behavior and can be a follow-up issue rather than a blocker.

---

Everything else is correct

• aria-pressed={isLiked} is present — ARIA toggle button semantics are correct
• likeDelta formula (isLiked ? 1 : 0) - (likedAtLoad.current ? 1 : 0) is mathematically sound; Math.max(0, likeCount + likeDelta) prevents negative display counts
• likedAtLoad.current ref resets correctly via useEffect when feedUrl changes
• Per-item try/catch in applyLikeChanges is consistent with queue processor error handling
• isLoading includes isInitializing, so button is disabled during DB load
• useLike.test.ts covers loading, liked/not-liked, toggle both directions, no-op while initializing, and error path
• queueProcessor.test.ts covers endpoint routing and encoding for both new action types
• LikeSync[] is a top-level named import in useSync.ts — no inline import() anywhere
• Schema v6 is a correct additive migration; comment about future composite key is useful
• Sync pull integration (step 8 in useSync.ts) follows the established pattern for subscriptions and play statuses
• e.stopPropagation() in handleClick is correct for a button nested inside a clickable card

---

Summary

The implementation is solid and all issues from prior reviews are already addressed in the code. The non-atomic db.likes + db.syncQueue operations in toggleLike is the one item worth looking at before merge — either fix with a Dexie transaction or confirm it's intentionally consistent with how other queue-backed operations work in this codebase.

[claude]

Code Review: feat: add like/unlike system for podcasts

This is an eighth review. Seven prior reviews exist — many contain claims not grounded in the actual diff. I've read the complete diff before writing this.

---

Confirmed correct (addressing prior review inaccuracies)

All of the following are present and correct in the actual diff:

• aria-pressed={isLiked} — present on the <button> in LikeButton.tsx
• LikeSync top-level import — imported via import type { LikeSync } from "../services/sync/client" at the top of useSync.ts
• likedAtLoad.current reset — handled by a useEffect(() => { likedAtLoad.current = null; }, [feedUrl]) with a biome-ignore comment explaining the intent
• Per-item try/catch in applyLikeChanges — each iteration is independently wrapped; one bad record won't abort the sync
• Likes pulled during sync — response.likes is processed at step 8 in the useSync sync flow
• Tests for useLike — 7 tests in useLike.test.ts covering loading, liked, not-liked, toggle both ways, no-op while initializing, and error path
• Tests for queueProcessor — 4 new tests covering endpoint routing and body encoding for both new action types
• _itemId, likes.liked i18n key, unlikeEpisode() — none of these exist in this PR

---

One genuine issue

🟡 Non-atomic like + sync queue operations in toggleLike

// src/hooks/useLike.ts — like path
await db.likes.put(newLike);     // succeeds
await db.syncQueue.add({...});   // if this throws, local state diverges

Same applies to the unlike path. If the first write succeeds and the second fails, the local like state changes but no action is queued — the next sync won't propagate the change to the server. In practice this is rare (both writes go to the same IndexedDB), but a Dexie transaction would make the pair atomic:

await db.transaction('rw', [db.likes, db.syncQueue], async () => {
  await db.likes.put(newLike);
  await db.syncQueue.add({ action: 'likePodcast', payload: { feedUrl }, createdAt: Date.now(), attempts: 0 });
});

Worth checking if subscribe/unsubscribe in the existing codebase have the same pattern — if they do, this is consistent behavior and a follow-up issue is acceptable.

---

Minor observation

Optimistic count disappears at 0

{displayCount != null && displayCount > 0 && <span className="text-xs">{displayCount}</span>}

When a podcast has 1 like and the user unlikes it, the count vanishes (0 is hidden). This is a design choice — just worth being intentional about it. If the intention is "don't show 0 likes", this is correct. If the count should always be visible when previously non-zero, a different condition is needed.

---

Overall

The implementation is well-structured. The likeDelta optimistic count formula (isLiked ? 1 : 0) - (likedAtLoad.current ? 1 : 0) correctly handles all four initial × current state combinations. The discriminated union types, Dexie live query pattern, and sync integration all follow established project patterns cleanly.

The non-atomic operations are the one thing worth addressing — either with a Dexie transaction or by confirming it's consistent with how the existing queue-backed operations work.