mirror of
https://github.com/Comfy-Org/desktop.git
synced 2026-11-04 23:47:43 +00:00
[GH-ISSUE #1405] SHOW_DIRECTORY_PICKER and preload typing don’t reflect cancellation / undefined result #400
Labels
No labels
area: desktop-app
Bounty
bug
bug-cop:answered
bug-cop:response-received
component: installer
component: preload
custom node
dependencies
Design
documentation
duplicate
enhancement
expected
frontend
good first issue
installation
Low-Priority
performance
Planned
platform: cross-platform
platform: windows
Potential Bug
Potential Bug
pull-request
question
refactor
Release
stale
User Support
V1
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Comfy-Org/desktop#400
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @benceruleanlu on GitHub (Nov 19, 2025).
Original GitHub issue: https://github.com/Comfy-Org/desktop/issues/1405
Summary
The
SHOW_DIRECTORY_PICKERIPC handler can returnundefinedwhen the user cancels the dialog, but the preload typing exposes it asPromise<string>. Most current call sites defensively checkif (result), so runtime behavior is fine today, but the type mismatch is misleading and could lead to future misuse.Current behavior
In
src/handlers/pathHandlers.ts:result.canceledwill betrueandresult.filePathswill be an empty array, sofilePaths[0]isundefined.In
src/preload.ts:So the preload API claims the function always resolves to a
string, but the implementation actually returnsstring | undefined.Frontend usage
In
frontend-2/apps/desktop-ui/src/components/install/InstallLocationPicker.vueandMigrationPicker.vue:The components already guard with
if (result)so they behave correctly at runtime when the user cancels.Issues
Promise<string>) and possible values (string | undefined) is confusing and can lead to:Expected behavior
undefinedwhen the user cancels.{ path?: string; canceled: boolean }) to make usage and typing even clearer.Possible improvements
Adjust the preload type to
Promise<string | undefined>src/preload.ts, change:to:
undefinedcase.Optionally, make cancelation explicit
{ path?: string; canceled: boolean }, and update the preload type accordingly.Add a small unit test for cancelation
tests/unit/handlers/pathHandler.test.ts, add a case wheredialog.showOpenDialogreturns{ filePaths: [], canceled: true }and assert that the handler resolves toundefined.Impact
Suggested work
Promise<string | undefined>.┆Issue is synchronized with this Notion page by Unito
@dosubot[bot] commented on GitHub (Nov 19, 2025):
You're right about the type mismatch: the SHOW_DIRECTORY_PICKER handler can return undefined on cancellation, but the preload and IPC channel typings currently claim it always returns a string. This could lead to future misuse if callers skip the cancellation check.
To fix this, update the return type in both the preload API and the IPC channel definition to Promise<string | undefined> and string | undefined, respectively. This matches the actual behavior and encourages correct handling. There's already a broader effort in the repo to address similar IPC type mismatches and ensure type safety across the IPC boundary (see here, and here).
There's also a gap in unit test coverage: the current tests only check the happy path (directory selected), not the cancellation case. Adding a test where dialog.showOpenDialog returns { filePaths: [], canceled: true } and asserting that the handler returns undefined would document and verify the intended behavior (see current test).
If you want to make cancellation even more explicit, you could return an object like { path?: string; canceled: boolean } from the handler and update the typing throughout, but this would be a larger API change.
In summary: update the typings to reflect the real return type, add a cancellation test, and optionally consider a more explicit return structure if you want to make intent even clearer. This will make the API safer and more maintainable.
To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.