The GitHub Actions job "Required Checks" on texera.git/fix/hub-workflow-covers has succeeded. Run started by GitHub user mengw15 (triggered by mengw15).
Head commit for run: b4ab0df3e871d9a85a0c9ac7cd285e7b65756c46 / Tanishq Gandhi <[email protected]> fix(frontend): render workflow covers 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 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 #8382. Report URL: https://github.com/apache/texera/actions/runs/35569484001 With regards, GitHub Actions via GitBox
