tanishqgandhi1908 opened a new pull request, #8383:
URL: https://github.com/apache/texera/pull/8383
### 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-section` only ever 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. So
nothing was ever cached for a workflow and `getCoverImage` fell through to the
default.
`getCoverImage` now reads a workflow's cover straight off the entry,
mirroring the branch `card-item.component.ts:197-202` already had.
Also included, since it is one line in the same area and needs no separate
issue: `frontend/proxy.config.json` declared `"/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 reads `dataset`, `model`,
`access/dataset`, `access/model`.
**Before** — both workflows are public; the left one has a cover, the right
one does not:
<img width="1440" height="900" alt="issue5-1-hub-landing-before"
src="https://github.com/user-attachments/assets/120c2cf3-2ee9-49e0-97df-a77e3746275c";
/>
**After** — the left card renders its cover, the right one still shows the
placeholder:
<img width="1440" height="900" alt="issue5-1-hub-landing-after"
src="https://github.com/user-attachments/assets/9c0294a0-f081-4428-a230-80281a40cb7a";
/>
### 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 workflow
with 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` — a
dataset 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
undefined` was already
there and asserted `getCoverImage(workflow) === defaultBackground` — it
pinned the bug, so it now
asserts the cover comes off the entry, with the unregistered-kind row
still falling back.
`landing-page.component.spec.ts` also run, 17 passed.
```
cd frontend
npx ng test --include
src/app/hub/component/browse-section/browse-section.component.spec.ts
npx ng test --include
src/app/hub/component/landing-page/landing-page.component.spec.ts
```
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)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
