Skip to content

Duplicated list_dir bindings swallow directory-iterator errors #890

Description

@sanchitmonga22

Follow-up from #808 by @shubhamsinnh — thanks again for that PR!

What

The four binding copies of list_dir (bindings/electron/native/posix_platform_adapter.cpp:296, bindings/electron/native/win32_platform_adapter.cpp:264,281-282, and the matching Python files) already drift from core/src/desktop/desktop_adapter.cpp. Most visibly, their directory_iterator loop ends silently on an error and the function still returns RAC_SUCCESS with a partial or empty listing, whereas the core adapter returns filesystem_error_to_rac(ec, ...) (desktop_adapter.cpp:283-285,320-322). The core adapter also filters hidden entries, masks is_dir on a type error, and logs skipped oversized names — none of which the four binding copies do.

Why it matters

Today the blast radius is small: model_registry_refresh.cpp treats an iterator error and an empty success listing the same way (it just skips the directory). But #808 needed the exact same 3-line fix pasted into four files because there's no shared implementation, so this class of bug will keep recurring.

Suggested approach

Share one list_dir implementation across the Electron and Python bindings, or at minimum port the core adapter's iterator-error handling into the four binding copies. Note the Electron RAC_DESKTOP_ADAPTER=OFF lane (win-arm64 / QHexRT) doesn't link the core desktop adapter, so sharing it outright isn't a drop-in change.

Done when

  • All four binding list_dir implementations return an error result (not RAC_SUCCESS with a partial listing) when the directory iterator itself fails, matching the core desktop adapter's contract.

Not blocking #808. @shubhamsinnh, you know this code well now — you're welcome to take this one if you're interested.

Opened with help from Claude Code and Codex.

Reviewed with help from Claude Code and Codex.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions