Channel health status and a repair action for stale community ids #145

New issue

Closed

opened 2026-08-14 21:59:14 +02:00 by myrmidex · 1 comment

myrmidex commented

2026-08-14 21:59:14 +02:00

Owner

Problem

Publishing to Lemmy fails with couldnt_find_community because channels hold
community ids that no longer resolve on their instance. Nine failures were
observed on 2026-08-14 between 17:42 and 18:06.

The local newsbottest and news channels hold community ids 101 and 102,
while the instance reports 217 and 8.

Root cause

The migration 2024_01_01_000015_store_numeric_community_id_on_platform_channels
failed during the v1.3.7 deploy. A Lemmy login returned login_token_pkey
during the migration, so the numeric community ids were never resolved and the
channels were left holding whatever was there before.

This is a one-off deploy failure rather than an ongoing bug in the resolution
code, but nothing in the app surfaces the resulting broken state, and nothing
offers a way to fix it.

Why it cannot be fixed through the UI today

Deleting and recreating the channel is currently the only route, and #141
"Delete channels from the UI, with a defined cascade" deliberately made that
possible for exactly this reason.

The channel edit modal has no community selector. This is deliberate: the
community and instance pairing is treated as immutable once created
(resources/views/livewire/channels.blade.php:342 and
app/Livewire/Channels.php:186 both state this). Only the create modal offers
community selection.

So a user whose channel has a stale id must delete it, losing its routes,
keywords, route articles and publications through the cascade, and recreate it.
That is a heavy fix for a stored value that has simply gone out of date.

Proposed

Two parts, both scoped to avoid reopening the "should channels be editable"
question:

1. Channel health status. Check whether a channel's stored community id
still resolves on its instance, and surface the result on the channel card.
LemmyApiService::resolveCommunityId() already does the lookup. A scheduled
check would fit alongside CheckPlatformCredentialsJob, which already runs
daily and reports account health the same way.

2. Repair action. Where a channel is unhealthy but its community name still
resolves, offer a per-channel action to re-resolve and store the correct id.
This repairs the pairing without making it freely editable: the community is
not being changed, only the stored id corrected to match what the instance
reports for the same community.

Open questions

Detection frequency. Daily alongside credentials, or on demand from the
channel card? A stale id only changes when something upstream changes, so
daily is likely enough, but on-demand gives the user a way to confirm a fix.
What "unhealthy" covers. A community that has been deleted or renamed
upstream cannot be repaired by re-resolving, and needs delete-and-recreate.
The status should distinguish "id is stale, repairable" from "community is
gone".
Whether the repair should be automatic. Re-resolving silently on a failed
publish would fix this class of failure without user involvement, but hides a
state change the user may want to know about.

Acceptance criteria

A channel whose stored community id no longer resolves is visibly marked
as unhealthy in the UI
The health state distinguishes a repairable stale id from a community that
no longer exists
A repair action re-resolves and stores the correct id for a repairable
channel
Repairing does not alter the community or instance pairing
Publishing succeeds again after a repair, verified against a channel in the
broken state
Tests cover: healthy channel, stale-but-repairable channel, missing
community, and repair restoring publish capability
Lemmy API calls are mocked in tests, per the LemmyApiService notes in
.claude/PLATFORM.md

#141 delete channels, currently the only workaround
#114 validates the community exists at creation time, which prevents new
channels entering this state but does nothing for existing ones
#142 surfaces failed publishes, which is how these failures become visible at
all

## Problem Publishing to Lemmy fails with `couldnt_find_community` because channels hold community ids that no longer resolve on their instance. Nine failures were observed on 2026-08-14 between 17:42 and 18:06. The local `newsbottest` and `news` channels hold community ids 101 and 102, while the instance reports 217 and 8. ## Root cause The migration `2024_01_01_000015_store_numeric_community_id_on_platform_channels` failed during the v1.3.7 deploy. A Lemmy login returned `login_token_pkey` during the migration, so the numeric community ids were never resolved and the channels were left holding whatever was there before. This is a one-off deploy failure rather than an ongoing bug in the resolution code, but nothing in the app surfaces the resulting broken state, and nothing offers a way to fix it. ## Why it cannot be fixed through the UI today Deleting and recreating the channel is currently the only route, and #141 "Delete channels from the UI, with a defined cascade" deliberately made that possible for exactly this reason. The channel edit modal has no community selector. This is deliberate: the community and instance pairing is treated as immutable once created (`resources/views/livewire/channels.blade.php:342` and `app/Livewire/Channels.php:186` both state this). Only the create modal offers community selection. So a user whose channel has a stale id must delete it, losing its routes, keywords, route articles and publications through the cascade, and recreate it. That is a heavy fix for a stored value that has simply gone out of date. ## Proposed Two parts, both scoped to avoid reopening the "should channels be editable" question: **1. Channel health status.** Check whether a channel's stored community id still resolves on its instance, and surface the result on the channel card. `LemmyApiService::resolveCommunityId()` already does the lookup. A scheduled check would fit alongside `CheckPlatformCredentialsJob`, which already runs daily and reports account health the same way. **2. Repair action.** Where a channel is unhealthy but its community name still resolves, offer a per-channel action to re-resolve and store the correct id. This repairs the pairing without making it freely editable: the community is not being changed, only the stored id corrected to match what the instance reports for the same community. ## Open questions - **Detection frequency.** Daily alongside credentials, or on demand from the channel card? A stale id only changes when something upstream changes, so daily is likely enough, but on-demand gives the user a way to confirm a fix. - **What "unhealthy" covers.** A community that has been deleted or renamed upstream cannot be repaired by re-resolving, and needs delete-and-recreate. The status should distinguish "id is stale, repairable" from "community is gone". - **Whether the repair should be automatic.** Re-resolving silently on a failed publish would fix this class of failure without user involvement, but hides a state change the user may want to know about. ## Acceptance criteria - [ ] A channel whose stored community id no longer resolves is visibly marked as unhealthy in the UI - [ ] The health state distinguishes a repairable stale id from a community that no longer exists - [ ] A repair action re-resolves and stores the correct id for a repairable channel - [ ] Repairing does not alter the community or instance pairing - [ ] Publishing succeeds again after a repair, verified against a channel in the broken state - [ ] Tests cover: healthy channel, stale-but-repairable channel, missing community, and repair restoring publish capability - [ ] Lemmy API calls are mocked in tests, per the `LemmyApiService` notes in `.claude/PLATFORM.md` ## Related - #141 delete channels, currently the only workaround - #114 validates the community exists at creation time, which prevents new channels entering this state but does nothing for existing ones - #142 surfaces failed publishes, which is how these failures become visible at all

myrmidex added this to the v1.5.0 milestone 2026-08-14 21:59:14 +02:00

myrmidex added the

bug

label 2026-08-14 21:59:14 +02:00

myrmidex referenced this issue

2026-08-15 01:59:33 +02:00

Migration 000015 authenticates against Lemmy and blocks every migration behind it #150

myrmidex modified the milestone from v1.5.0 to v1.4.1

2026-08-15 10:26:45 +02:00

myrmidex commented

2026-08-15 10:35:50 +02:00

Author

Owner

Closing: superseded by the approach taken in #150.

Migration 000015 no longer resolves community ids against the instance. It
deletes channels whose channel_id is still a slug and keeps the numeric ones,
so after it runs a channel either holds a valid id or does not exist. There is
no unresolved state left to detect or repair, and the repair action this ticket
proposed has nothing to act on.

Channels are recreated through the Channels page, which already validates that
the community exists on the instance (#114), so a recreated channel cannot enter
the broken state this ticket described.

The narrower concern behind this ticket still exists in principle: a community
id that is valid at creation could go stale later if the community is deleted or
the instance renumbers. That has not been observed, and the failure is now
visible on the Failed tab (#142) rather than silent. Worth a fresh ticket if it
ever happens, rather than keeping this one open against a state the schema no
longer permits.

Closing: superseded by the approach taken in #150. Migration `000015` no longer resolves community ids against the instance. It deletes channels whose `channel_id` is still a slug and keeps the numeric ones, so after it runs a channel either holds a valid id or does not exist. There is no unresolved state left to detect or repair, and the repair action this ticket proposed has nothing to act on. Channels are recreated through the Channels page, which already validates that the community exists on the instance (#114), so a recreated channel cannot enter the broken state this ticket described. The narrower concern behind this ticket still exists in principle: a community id that is valid at creation could go stale later if the community is deleted or the instance renumbers. That has not been observed, and the failure is now visible on the Failed tab (#142) rather than silent. Worth a fresh ticket if it ever happens, rather than keeping this one open against a state the schema no longer permits.

myrmidex closed this issue

2026-08-15 10:35:57 +02:00