A public visitor following a stale link to a channel that no longer exists produces an
ERR. The behaviour is correct; the log level is not.
Where: HomebaseChannelContentService.GetChannelDrive, reached from
HomebasePublicPageService.TryWritePostPreview → TryGetPostData → TryParsePostFile.
Failed to parse post (Could not find drive by channel key (articles))
Odin.Core.Exceptions.OdinClientException: Could not find drive by channel key (articles)
Why it happens
The identity was deleted and recreated. The recreated identity does not carry the old
channel drives, so links minted against the previous incarnation — caches, crawlers,
other people's posts — now point at a channel key that no longer resolves.
Deleting and recreating an identity is supported, so the condition it produces is
expected and permanent. Dead links on a public web surface never go away.
The defect
Returning not-found is right. Logging it at ERR is not: the exception type is
OdinClientException — a client error by definition — and no one can act on it, ever.
The codebase already agrees in most paths. Across 2026-08-30..31 on production:
| date |
level |
channel key |
| 2026-08-30 |
DBG |
releases |
| 2026-08-30 |
DBG |
releases |
| 2026-08-31 |
DBG |
releases |
| 2026-08-31 |
ERR |
articles |
Three at DBG, one at ERR, for the same class of condition. ERR here is the outlier, not a
considered severity choice.
Suggested fix
Log OdinClientException on the public-page path at WRN or INF. If a missing channel
drive is ever genuinely server-side, that case deserves its own exception type rather
than a shared level.
Low severity, but every stale link produces a permanent unactionable ERR — this sweep
found 5 production errors in a day and one of them was this.
Maintained by logmeister; body revised in place as evidence changes. Identity domains redacted.
logmeister-fp: fffa9c5a
A public visitor following a stale link to a channel that no longer exists produces an
ERR. The behaviour is correct; the log level is not.Where:
HomebaseChannelContentService.GetChannelDrive, reached fromHomebasePublicPageService.TryWritePostPreview→TryGetPostData→TryParsePostFile.Why it happens
The identity was deleted and recreated. The recreated identity does not carry the old
channel drives, so links minted against the previous incarnation — caches, crawlers,
other people's posts — now point at a channel key that no longer resolves.
Deleting and recreating an identity is supported, so the condition it produces is
expected and permanent. Dead links on a public web surface never go away.
The defect
Returning not-found is right. Logging it at
ERRis not: the exception type isOdinClientException— a client error by definition — and no one can act on it, ever.The codebase already agrees in most paths. Across 2026-08-30..31 on production:
releasesreleasesreleasesarticlesThree at DBG, one at ERR, for the same class of condition. ERR here is the outlier, not a
considered severity choice.
Suggested fix
Log
OdinClientExceptionon the public-page path atWRNorINF. If a missing channeldrive is ever genuinely server-side, that case deserves its own exception type rather
than a shared level.
Low severity, but every stale link produces a permanent unactionable
ERR— this sweepfound 5 production errors in a day and one of them was this.
Maintained by logmeister; body revised in place as evidence changes. Identity domains redacted.
logmeister-fp: fffa9c5a