Skip to content

fix: Add application nodes in advanced orchestration, unpublished applications are not filtered out #3820

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
merged 1 commit into from
Aug 5, 2025
Merged

fix: Add application nodes in advanced orchestration, unpublished applications are not filtered out #3820

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/views/application-workflow/component/DropdownMenu.vue
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -277,7 +277,7 @@ async function getApplicationList() {
folder_id: folder.currentFolder?.id || user.getWorkspaceId(),
})
applicationList.value = res.data.filter(
(item: any) => item.resource_type === 'application' && item.id !== props.id,
(item: any) => item.resource_type === 'application' && item.id !== props.id && item.is_publish,
)
}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The provided code is mostly correct, but there are a few areas to consider:

  1. Type Annotations: While TypeScript annotations (any) can be useful for dynamic typing, they make it harder to catch type errors. Consider explicitly defining types for item, such as an interface or type. This will help catch issues at compile time.

  2. Error Handling: The function does not include error handling mechanisms. If the API call fails, no alert or exception is thrown. It would be beneficial to add try-catch blocks around the API call to handle these cases gracefully.

  3. Code Organization: While the logic looks clean, you might want to further divide the functionality into smaller, reusable functions if this function grows in complexity.

  4. Performance Considerations: Ensure that the filtering operation on res.data is efficient. If applicationList.value could potentially contain a lot of data, consider memoization techniques or more optimized filtering strategies.

Here's an example with improved type annotations and added exception handling:

async async getApplicationList() {
  let folderId;
  
  try {
    const workspaceId = user.getWorkspaceId();
    
    // Fetch folder ID or use default workspace ID
    const response = await axios.get('/api/folders/current', { params: { workspaceId } });
    folderId = response.data?.folder?.id || workspaceId;

    const res = await fetchApplications(folderId);
    applicationList.value = res.data.filter((item: ApplicationItem) => {
      return item.resource_type === 'application' && item.id !== props.id && item.is_publish;
    });

    console.log('Successfully fetched application list');
  } catch (error) {
    console.error('Failed to fetch applications:', error);
    // Implement fallback mechanism or show an error message to the user
  }
}

Additional Recommendations:

  • Environment Variables: Replace hardcoded URL paths like /api/folders/current with environment variables or configuration settings to improve maintainability.
  • API Call: Use appropriate HTTP libraries or Axios consistently throughout your codebase for consistent API interactions.
  • Testing: Write tests to cover different scenarios and edge cases, including failed API calls, to ensure robustness of the function.

Expand Down
4 changes: 0 additions & 4 deletions ui/src/workflow/common/NodeCascader.vue
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -53,10 +53,6 @@ function visibleChange(bool: boolean) {
options.value = props.global
? props.nodeModel
.get_up_node_field_list(false, true)
.map((v: any) => {
console.log(v)
return v
})
.filter(
(v: any) => ['global', 'chat'].includes(v.value) && v.children && v.children.length > 0,
)
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This code does not contain any obvious errors, but there are some areas that could be improved for better performance and readability:

  1. Avoid Using map Inside Filter: The current implementation uses map inside the filter function to log each element before filtering. This is redundant because logging an element does not affect its inclusion in the filtered result.

  2. Reduce Nesting Level: You can simplify the expression within the map function by removing the unnecessary wrapping with anonymous functions. Here’s how you can improve it:

    if (['global', 'chat'].includes(item.value) && item.children && item.children.length > 0) {
  console.log(item);
  return item;
}

  3. Consider Caching Results: If this function is called frequently and potentially involves expensive operations, consider caching results of expensive expressions like nodeModel.get_up_node_field_list() so they do not need re-computation unless necessary.

  4. Error Handling: Ensure robust error handling is in place, especially around props.nodeModel, which might throw exceptions under certain conditions. This can prevent runtime errors from breaking the rest of your application.

Here's the refined version of the code based on these observations:

function visibleChange(bool: boolean) {
  const fields = props.global ? props.nodeModel.get_up_node_field_list(false, true).filter(
    (item: any) => ['global', 'chat'].includes(item.value) && item.children && item.children.length > 0
  );
  
  fields.forEach((field: any) => {
    console.log(field); // Log field only when included in the final list
  });

  options.value = fields; // Update options value only after processing
}

These changes make the code cleaner and more efficient while maintaining the intended functionality.

Expand Down
Loading