Adds support for malformed channel URLs (thx grok)#3412
Conversation
📝 WalkthroughWalkthroughThis PR introduces a channel path correction system that detects malformed LBRY channel URLs missing the @ prefix and automatically redirects to corrected paths. The feature includes server-side correction during HTML generation and request handling, plus client-side correction with redirect during claim rendering. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@web/src/html.js`:
- Line 24: In the resolveClaimOrRedirect function locate the branch that handles
a corrected URL (where getCorrectedChannelUri/normalizeClaimUrl is used) and
change it so the redirect is conditional: if ignoreRedirect is true return the
resolved claim/claim object (no redirect) otherwise perform the existing
redirect behavior; ensure you reference resolveClaimOrRedirect and
getCorrectedChannelUri (and normalizeClaimUrl if used) when making the change
and apply the same guard to the other corrected-URL branch around lines 496-507.
web/src/html.js
Outdated
| const { lbryProxy: Lbry } = require('../lbry'); | ||
| const { getHomepageJsonV1 } = require('./getHomepageJSON'); | ||
| const { buildURI, parseURI, normalizeClaimUrl } = require('./lbryURI'); | ||
| const { buildURI, parseURI, normalizeClaimUrl, getCorrectedChannelUri } = require('./lbryURI'); |
There was a problem hiding this comment.
Respect ignoreRedirect when corrected URI resolves.
resolveClaimOrRedirect is called with ignoreRedirect=true for embed/playlist flows, but the corrected-URL branch always redirects. That bypasses the contract and can kick embed requests to the normal page. Gate the redirect on ignoreRedirect, and return the claim otherwise.
Suggested fix
- if (correctedUrl) {
- const correctedResponse = await Lbry.resolve({ urls: [correctedUrl] });
- if (correctedResponse && correctedResponse[correctedUrl] && !correctedResponse[correctedUrl].error) {
- // Redirect to the correct URL with @ prefix
- const correctedWebUrl = correctedUrl.replace('lbry://', '/').replace(/#/g, ':');
- ctx.redirect(correctedWebUrl);
- return;
- }
- }
+ if (correctedUrl) {
+ const correctedResponse = await Lbry.resolve({ urls: [correctedUrl] });
+ if (correctedResponse && correctedResponse[correctedUrl] && !correctedResponse[correctedUrl].error) {
+ if (!ignoreRedirect) {
+ const correctedWebUrl = correctedUrl.replace('lbry://', '/').replace(/#/g, ':');
+ ctx.redirect(correctedWebUrl);
+ return;
+ }
+ claim = correctedResponse[correctedUrl];
+ }
+ }Also applies to: 496-507
🤖 Prompt for AI Agents
In `@web/src/html.js` at line 24, In the resolveClaimOrRedirect function locate
the branch that handles a corrected URL (where
getCorrectedChannelUri/normalizeClaimUrl is used) and change it so the redirect
is conditional: if ignoreRedirect is true return the resolved claim/claim object
(no redirect) otherwise perform the existing redirect behavior; ensure you
reference resolveClaimOrRedirect and getCorrectedChannelUri (and
normalizeClaimUrl if used) when making the change and apply the same guard to
the other corrected-URL branch around lines 496-507.
Addresses an issue where channel URLs from platforms like Grok/Twitter may omit the "@" prefix.
tzarebczan
force-pushed
the
fix-bad-grok-urls
branch
from
f1115c7 to
f7c76ae
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@ui/hocs/withResolvedClaimRender/view.jsx`:
- Around line 43-76: The function getCorrectedChannelPath currently treats any
two-segment path like "name/name" as a channel by prepending "@", which can
false-positive for legitimate non-channel nested claim paths; update the
function by adding a clear JSDoc comment above getCorrectedChannelPath that
documents the assumption (this HOC only runs on claim pages, and any two-segment
path missing "@" will be treated as a channel/content path and auto-prefixed),
describe the expected input/outputs and the low-risk caveat about possible
non-channel nested paths, and include an example or note that callers should
avoid invoking this function for known non-channel routes.
🧹 Nitpick comments (1)
ui/hocs/withResolvedClaimRender/view.jsx (1)
43-76: Code duplication — consider extractinggetCorrectedChannelPathto a shared utility.This function reimplements the same logic as
getCorrectedChannelWebPathfromweb/src/lbryURI.js. The main difference is thatgetCorrectedChannelPathhandles browser URL paths (with leading slash), while the server-side version does not. If shared, this function could be added toui/util/lbryURI.jswith appropriate input normalization, or a shared utility module could be created to serve both client and server code paths.
| function getCorrectedChannelPath(pathname: string): ?string { | ||
| try { | ||
| // Remove leading slash | ||
| const webPath = pathname.startsWith('/') ? pathname.slice(1) : pathname; | ||
|
|
||
| // Must have a slash with content after it (channel/content pattern) | ||
| const slashIndex = webPath.indexOf('/'); | ||
| if (slashIndex === -1 || slashIndex === webPath.length - 1) { | ||
| return null; | ||
| } | ||
|
|
||
| const firstPart = webPath.substring(0, slashIndex); | ||
| const secondPart = webPath.substring(slashIndex + 1); | ||
|
|
||
| // First part should not already start with @ | ||
| if (firstPart.startsWith('@')) { | ||
| return null; | ||
| } | ||
|
|
||
| // Both parts should have content (non-empty name before any modifiers) | ||
| // Modifiers in web URLs use : instead of # | ||
| const firstNameMatch = firstPart.match(/^[^#:$*]+/); | ||
| const secondNameMatch = secondPart.match(/^[^#:$*]+/); | ||
|
|
||
| if (!firstNameMatch || !firstNameMatch[0] || !secondNameMatch || !secondNameMatch[0]) { | ||
| return null; | ||
| } | ||
|
|
||
| // Return the corrected path with @ prefix | ||
| return `/@${webPath}`; | ||
| } catch (e) { | ||
| return null; | ||
| } | ||
| } |
There was a problem hiding this comment.
Heuristic may false-positive on non-channel two-segment claim paths.
getCorrectedChannelPath adds @ to any "name/name" path where the first segment lacks @. If a legitimate non-channel claim ever has a nested path pattern (without @), this would incorrectly redirect it. The risk is low since this HOC is only rendered for claim pages and LBRY channel/content paths use the @channel/content convention, but it's worth documenting this assumption in the function's JSDoc.
🧰 Tools
🪛 Biome (2.3.13)
[error] 43-43: Type annotations are a TypeScript only feature. Convert your file to a TypeScript file or remove the syntax.
TypeScript only syntax
(parse)
[error] 43-43: return types can only be used in TypeScript files
(parse)
[error] 43-43: Expected a function body but instead found '?'.
Expected a function body here.
(parse)
[error] 51-51: Illegal return statement outside of a function
(parse)
[error] 59-59: Illegal return statement outside of a function
(parse)
[error] 68-68: Illegal return statement outside of a function
(parse)
[error] 72-72: Illegal return statement outside of a function
(parse)
[error] 74-74: Illegal return statement outside of a function
(parse)
🤖 Prompt for AI Agents
In `@ui/hocs/withResolvedClaimRender/view.jsx` around lines 43 - 76, The function
getCorrectedChannelPath currently treats any two-segment path like "name/name"
as a channel by prepending "@", which can false-positive for legitimate
non-channel nested claim paths; update the function by adding a clear JSDoc
comment above getCorrectedChannelPath that documents the assumption (this HOC
only runs on claim pages, and any two-segment path missing "@" will be treated
as a channel/content path and auto-prefixed), describe the expected
input/outputs and the low-risk caveat about possible non-channel nested paths,
and include an example or note that callers should avoid invoking this function
for known non-channel routes.
1 participant
Addresses an issue where channel URLs from platforms like Grok/Twitter may omit the "@" prefix.
Implements logic to detect and correct these malformed URLs, ensuring correct resolution and redirection.
This improves the user experience by handling cases where users encounter broken links due to missing "@" symbols in channel URLs.
Fixes
Issue Number:
What is the current behavior?
What is the new behavior?
Other information
PR Checklist
Toggle...
What kind of change does this PR introduce?
Please check all that apply to this PR using "x":
Summary by CodeRabbit
Release Notes