fix(frontend): render workflow covers on the hub landing page - #8383
Merged
Conversation
Every card under Top Loved Workflows and Top Cloned Workflows showed the grey
placeholder, even for a workflow whose owner had set a cover, while the same
workflow rendered it correctly in Your Work.
Covers reach the frontend two different ways. A workflow's is a downscaled data
URL that arrives inline on the list payload and lands on
DashboardEntry.coverImageUrl. A dataset's or model's is a committed file, so
what arrives is a path and the card fetches a presigned URL from
/{id}/cover-url. browse-section only handled the second kind: it asks the
descriptor for a coverUrl and bails when there is none, which is always the
case for a workflow, since WorkflowResourceDescriptor deliberately declares
none. Nothing was ever cached for a workflow, so getCoverImage fell through to
the default.
getCoverImage now reads a workflow's cover off the entry, mirroring the branch
card-item already had. It is deliberately not a blanket fallback for every
kind: a dataset or model carries a stored path such as v1/cover.png, which no
img can load, so a blanket fallback would swap a clean placeholder for a broken
image whenever the presigned fetch returned nothing. A spec pins that, and
datasets and models keep resolving exactly as before.
Also removes a duplicate "/api/model/**" key in frontend/proxy.config.json,
where both entries pointed at :9092 and the last silently won.
Closes apache#8382.
Yicong-Huang
added
release/v1.3
Contributor
Automated Reviewer SuggestionsBased on the
|
Contributor
Backport auto-label reportThis
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #8383 +/- ##
=========================================
Coverage 94.03% 94.04%
Complexity 4771 4771
=========================================
Files 1196 1196
Lines 48757 48760 +3
Branches 5916 5918 +2
=========================================
+ Hits 45850 45854 +4
Misses 1458 1458
+ Partials 1449 1448 -1
*This pull request uses carry forward flags. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
aicam
approved these changes
Sep 3, 2026
This was referenced Sep 3, 2026
Contributor
|
Backport PR opened: draft #8390 (#8390) to |
Contributor
|
Backport PR opened: draft #8389 (#8389) to |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this PR?
Workflow covers never rendered on the Hub landing page: every card under Top Loved Workflows and Top Cloned Workflows showed the grey placeholder, even for a workflow whose owner had set a cover, while the same workflow showed it correctly in Your Work → Workflows.
Covers reach the frontend two different ways. A workflow cover is a downscaled data URL that arrives inline on the list payload and lands on
DashboardEntry.coverImageUrl. A dataset or model cover is a committed file, so what arrives is a path and the card has to fetch a presigned URL from/{id}/cover-url.browse-sectiononly ever handled the second kind — it asks the descriptor for acoverUrland bails when there is none, which is always the case for a workflow, sinceWorkflowResourceDescriptordeliberately declares none. So nothing was ever cached for a workflow andgetCoverImagefell through to the default.getCoverImagenow reads a workflow's cover straight off the entry, mirroring the branchcard-item.component.ts:197-202already had.Also included, since it is one line in the same area and needs no separate issue:
frontend/proxy.config.jsondeclared"/api/model/**"twice (both pointing at:9092, so the last silently won). The duplicate is removed, leaving the entry beside/api/dataset, so the file readsdataset,model,access/dataset,access/model.Before — both workflows are public; the left one has a cover, the right one does not:
After — the left card renders its cover, the right one still shows the placeholder:
Any related issues, documentation, discussions?
Closes #8382.
How was this PR tested?
browse-section.component.spec.ts, 25 passed:renders a workflow's cover from the entry, since no cover is ever fetched for one— a workflowwith a cover resolves to it, one without still gets the default.
keeps a file-backed kind on the placeholder rather than rendering its stored cover path— adataset whose presigned fetch answers with an empty URL stays on the placeholder instead of
rendering
v1/images/preview.png.skips an entity whose descriptor resolves no cover, rather than calling undefinedwas alreadythere and asserted
getCoverImage(workflow) === defaultBackground— it pinned the bug, so it nowasserts the cover comes off the entry, with the unregistered-kind row still falling back.
landing-page.component.spec.tsalso run, 17 passed.Checked by hand against a local stack: a public workflow with a cover set from the dashboard now
shows it in both hub sections, and a public workflow without one is unchanged.
Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Opus 5)