Starred workflows created before upgrading to 1.17.1 link to /app

[nya1mo]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

After upgrading Dify from 1.16.1 to 1.17.1, I noticed that workflows created before the upgrade have an incorrect link when added to Starred Apps.

When I click one of these workflows from the Starred Apps menu, the link points only to:

{host_url}/app

instead of the expected workflow-specific URL:

{host_url}/app/{uuid}/workflow

As a result, clicking the starred workflow does not open the individual workflow page.

Interestingly, workflows newly created after upgrading to 1.17.1 work correctly.

I also tried removing the affected workflows from Starred Apps and adding them again, but the behavior did not change.

Does anyone know what might be causing this behavior or how to fix it?

2. Additional context or comments

Environment:

• Previous version: Dify 1.16.1
• Current version: Dify 1.17.1

Observed behavior:

• Workflows created before the upgrade: link becomes {host_url}/app
• Workflows created after the upgrade: link correctly includes the workflow UUID

[Kxrma47]

This looks like a migration/ACL payload regression, not stale Starred Apps membership. In Dify 1.17.1 the starred card passes the app object to getRedirectionPath(). A workflow gets /app/{id}/workflow only when its mode is workflow/advanced-chat and its permission payload allows layout access; otherwise the function falls back to the apps page.

Open DevTools → Network and compare the starred-app API objects for one old and one new workflow, especially:

{ "id": "...", "mode": "workflow", "permission_keys": ["..."] }

If the old object has a missing/wrong mode or different permission_keys, removing and re-adding the star cannot fix it because the underlying app/ACL record is unchanged. The safe temporary workaround is the direct /app/{uuid}/workflow URL. I would report the old/new API payload difference as a 1.16.1 → 1.17.1 migration bug rather than editing the database manually.

Sources: https://github.com/langgenius/dify/blob/1.17.1/web/app/components/apps/starred-app-card.tsx and https://github.com/langgenius/dify/blob/1.17.1/web/utils/app-redirection.ts

[Bruce-Yii]

Verified against current main (d6491af, Sep 21): the mechanism @Kxrma47 described is still exactly how it works, so this is worth filing as a migration bug once you have the payload diff.

StarredAppCard (web/app/components/apps/starred-app-card.tsx) builds its link via getRedirectionPath(app, { currentUserId, resourceMaintainer: app.maintainer, workspacePermissionKeys, isRbacEnabled }), and getRedirectionPath (web/utils/app-redirection.ts) returns /app/{id}/workflow for a workflow only when getAppACLCapabilities(app.permission_keys, ...).canAccessLayout is true — otherwise it falls through to overview/logs/access-config and finally the apps list. So a pre-1.17.1 workflow whose stored permission_keys (or maintainer attribution, which now feeds the ACL check) wasn't backfilled by the upgrade will deterministically fall back to the list page, and un-starring/re-starring can't help because the underlying app/ACL record is unchanged — matching what you observed.

Concrete next step: DevTools → Network, compare the starred-app API objects for one pre-upgrade and one post-upgrade workflow (id, mode, permission_keys, maintainer). If you paste the two payloads (redact host), the exact un-backfilled field should be identifiable, and that's the migration to patch. Workaround until then: the direct /app/{uuid}/workflow URL.

[nya1mo]

@Kxrma47
@Bruce-Yii

Thanks for the help.

I created an issue with the additional findings:
#42807

I'll close this discussion since the issue is now being tracked there.