Skip to content

fix: Dialogue Routing Handling #7827

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
shaohuzhang1 merged 1 commit into from
Nov 11, 2026
Merged

fix: Dialogue Routing Handling #7827

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion ui/src/router/chat/index.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ import { chatRoutes } from './routes'

const CHAT_BASE_PATH = window.MaxKB?.prefix || import.meta.env.VITE_BASE_PATH || '/chat/'

const chatRouter = createRouter({ history: createWebHistory(CHAT_BASE_PATH), routes: chatRoutes })
const chatRouter = createRouter({ history: createWebHistory(CHAT_BASE_PATH), strict: true, routes: chatRoutes })

const LOGIN_ROUTE_NAMES = new Set(['portal-login', 'chat-login'])

@shaohuzhang1 shaohuzhang1 Nov 11, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The primary issue is that strict is not a valid configuration option for the createRouter() function in Vue Router 4.

Analysis

  • Location: createRouter({ ..., strict: true, ... })
  • Problem: createRouter accepts a configuration object with keys like history, routes, scrollBehavior, etc. It does not accept strict. This property will simply be ignored by the router instance creation logic but may cause confusion, TypeScript errors (if types are strict), or linting issues.
  • Intent: You likely intended to enable trailing slash strictness (i.e., /chat/about and /chat/about/ are treated as different routes) or ensure exact route matching.

Solutions

Option 1: Use createWebHistory with strict trailing slash handling (Recommended if supported)

In recent versions of Vue Router, you can pass options to createWebHistory. Check if your version supports strict inside the history creator:

// Vue Router 4.x+ may support this depending on minor version
const history = createWebHistory(CHAT_BASE_PATH, { strict: true }) 
const chatRouter = createRouter({ 
  history, 
  routes: chatRoutes 
})

Note: Verify your specific Vue Router version. If { strict: true } isn't supported in createWebHistory, use Option 2 or 3.

Option 2: Handle it in Route Definitions (Exact Match)

If you want only one canonical path (e.g., no trailing slashes), normalize paths in chatRoutes or add a redirect/catch-all rule. This is more explicit but verbose.

Option 3: Use router.beforeEach for Normalization

To enforce "strict" behavior where extra trailing slashes are redirected or rejected:

chatRouter.beforeEach((to, from, next) => {
  // Remove trailing slash (except for root)
  const normalizedPath = to.path.length > 1 && to.path.endsWith('/')
    ? to.path.slice(0, -1)
    : to.path;

  if (normalizedPath !== to.path) {
    return next({ path: normalizedPath, query: to.query, hash: to.hash });
  }
  
  next();
});

Other Observations

  1. LOGIN_ROUTE_NAMES: Defined but unused in the provided snippet. Ensure it’s used elsewhere (likely in navigation guards).
  2. Environment Variable Fallback: The fallback chain window.MaxKB?.prefix || import.meta.env.VITE_BASE_PATH || '/chat/' is robust for build-time vs runtime config. Keep it.
  3. Type Safety: If using TypeScript, the strict: true property may cause a type error since it’s not part of RouterOptions.

Corrected Code (Safest Fix – Remove Invalid Property)

Unless you have a specific reason to keep strict (and verified it’s supported in your Vue Router version via createWebHistory options), remove it from createRouter:

import { createRouter, createWebHistory } from 'vue-router';
import { chatRoutes } from './routes';

const CHAT_BASE_PATH = window.MaxKB?.prefix || import.meta.env.VITE_BASE_PATH || '/chat/';

// ✅ Fixed: Removed invalid 'strict' property
const chatRouter = createRouter({
  history: createWebHistory(CHAT_BASE_PATH),
  routes: chatRoutes,
});

const LOGIN_ROUTE_NAMES = new Set(['portal-login', 'chat-login']);

export default chatRouter;

Recommendation: If strict trailing-slash behavior is required, implement normalization via router.beforeEach (Option 3 above), as it works across all Vue Router 4 versions reliably.

Expand Down
6 changes: 6 additions & 0 deletions ui/src/router/chat/routes.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -40,6 +40,12 @@ const applicationRoutes: RouteRecordRaw[] = [
name: 'chat-login',
component: () => import('@/views/chat/login/index.vue'),
meta: { title: '登录' },
},
{
path: '/:accessToken',
redirect: (to) => {
return `/${to.params.accessToken}/`
},
},
{
path: '/:accessToken/',

@shaohuzhang1 shaohuzhang1 Nov 11, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review Findings

Potential Issues

  1. Route Order & Prefix Conflict

    • /:accessToken is a catch-all-ish top-level param route placed before the existing /:accessToken/ route. Since Vue Router matches non-greedy dynamic segments, /:accessToken will also match single-segment paths like /chat-login (no trailing slash) unless that route was already registered above it. Make sure all static routes (e.g. chat-login) are declared before this dynamic route, otherwise they will be shadowed.

  2. Conflict With Static Single-Segment Routes

    • Any future top-level route with one segment (/login, /home, etc.) will become unreachable if declared after /:accessToken. Consider constraining the token with a regex: 
      {
  path: '/:accessToken(\\w{16,})', // adjust to real token format
  redirect: (to) => `/${to.params.accessToken}/`,
}

  3. Redirect Loop Risk

    • If a user lands on /:accessToken and redirects to /${token}/, ensure the /:accessToken/ route actually exists and handles navigation rather than redirecting back (would cause an infinite loop). Also verify that a request for / or // doesn't get captured by this rule.

  4. Trailing Slash Behavior Inconsistency

    • The two rules differ only by trailing slash. Depending on router config (strict: false by default in Vue Router 4), they may both match the same URL, causing ambiguity. Confirm whether strict mode is off — if so, the redirect rule may be redundant or may not trigger as expected.

  5. Missing redirect Validation

    • If to.params.accessToken contains special characters (slashes, ?#, etc.), string interpolation could break the URL. Use encodeURIComponent: 
      redirect: (to) => `/${encodeURIComponent(to.params.accessToken as string)}/`

  6. Empty / Malformed Token

    • There's no guard against empty tokens or reserved values (e.g. api, static), which would forward users to meaningless URLs.

  7. Indentation

    • The added block uses inconsistent indentation (3 spaces vs 2). Minor style/nit for linters.

  8. Type Safety

    • to.params.accessToken is typed as string | string[]. Cast or narrow to string to avoid potential type errors under vue-tsc.

Summary Suggestion

{
  path: '/:accessToken(\\w+)',
  redirect: (to) =>
    `/${encodeURIComponent(to.params.accessToken as string)}/`,
},

Place it after all static top-level routes, and confirm router strict mode expectations.

Expand Down
9 changes: 7 additions & 2 deletions ui/src/views/application-detail/overview/index.vue
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -50,12 +50,17 @@ const chatBasePath = CHAT_API_BASE_PATH.replace(/\/api$/, '')

const apiDocUrl = new URL(`${CHAT_API_BASE_PATH}-doc/`, window.location.origin).href
const apiQuery=computed(()=>{
return application.value?.work_flow?.nodes?.find(n=>n.id==='base-node')?.properties?.api_input_field_list.map((f:any)=>{
const query=application.value?.work_flow?.nodes?.find(n=>n.id==='base-node')?.properties?.api_input_field_list.map((f:any)=>{
return `${f.variable}=${f.default_value}`
}).join('&')
if(query){
return '?'+query
}
return ''

})
// TODO：访问链接还有问题
const accessUrl = computed(() => (accessToken.value ? `${window.location.origin}${chatBasePath}/${accessToken.value}?${apiQuery.value}` : ''))
const accessUrl = computed(() => (accessToken.value ? `${window.location.origin}${chatBasePath}/${accessToken.value}/${apiQuery.value}` : ''))

function toUrl(url?: string) {
if (!url) return

@shaohuzhang1 shaohuzhang1 Nov 11, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

Issues

1. URL path bug (line ~63) — the actual problem

`${...}/${accessToken.value}/${apiQuery.value}`

You changed ?${apiQuery.value} to /${apiQuery.value}, but apiQuery now already starts with ?. This produces a malformed URL like:

https://host/path/token/?var=val&var2=val2

The ? is preceded by a /, turning the query string into a path segment followed by a stray ?. It will almost certainly be broken.

Fix: revert to concatenation without an extra slash:

const accessUrl = computed(() =>
  accessToken.value
    ? `${window.location.origin}${chatBasePath}/${accessToken.value}${apiQuery.value}`
    : ''
)

Also, the trailing / issue: apiQuery.value is '' when no fields exist, so you'll end up with .../token/ (trailing slash). The previous code had .../token? (also odd). Consider trimming:

const suffix = apiQuery.value || ''

2. Missing optional chaining on .map()

.find(n => n.id === 'base-node')?.properties?.api_input_field_list.map(...)

If api_input_field_list is undefined, this throws. Add ?. before .map:

?.api_input_field_list?.map(...)

3. No URL encoding of values

return `${f.variable}=${f.default_value}`

f.variable and f.default_value are interpolated raw. Spaces, &, =, #, unicode, etc. will break the query string. Use encodeURIComponent:

return `${encodeURIComponent(f.variable)}=${encodeURIComponent(f.default_value ?? '')}`

Alternatively build with URLSearchParams — cleaner and handles encoding automatically.

4. == vs ===

n.id == 'base-node'

Use strict equality (===) to avoid type coercion surprises. (Pre-existing, but worth fixing while touched.)

5. Explicit typing / any

(f: any) loses type safety. If api_input_field_list items have a known shape ({ variable: string; default_value: string }), declare it:

interface ApiInputField { variable: string; default_value: string }

This also removes the need for as any.

6. default_value may be null/non-string

${null} → "null" in the URL. Guard with ?? '' or filter out empty entries.

Optimization suggestions

  • Refactor using URLSearchParams:
const apiQuery = computed(() => {
  const fields = application.value?.work_flow?.nodes
    ?.find(n => n.id === 'base-node')
    ?.properties?.api_input_field_list as ApiInputField[] | undefined

  if (!fields?.length) return ''

  const params = new URLSearchParams()
  for (const f of fields) {
    if (f.variable) params.append(f.variable, String(f.default_value ?? ''))
  }
  const qs = params.toString()
  return qs ? `?${qs}` : ''
})

Then in accessUrl just concatenate apiQuery.value (no slash).

  • Extract a small helper (buildChatUrl) so it's unit-testable and readable.
  • Consider guarding against non-absolute CHAT_API_BASE_PATH before constructing new URL(...).
  • Remove the stale // TODO：访问链接还有问题 comment only after confirming the fix, otherwise keep it accurate.

Summary of must-fix

  1. ${apiQuery.value} → remove the extra / in the template literal.
  2. Add ?. before .map.
  3. Encode values with encodeURIComponent / URLSearchParams.

Expand Down
Loading