kestra-io / kestra-io/plugin-dropbox

Several documented behaviors are no-ops or unreachable (List URI resolution, GetMetadata includeMediaInfo, Download path check)

Open
#64 0 comments 0 reactions 0 assignees View on GitHub
area/plugin good first issue
Dominant language
Java
Stars
2
Forks
2
Avg merge
1d 26m
Merged PRs (30d)
5

Description

### Describe the issue

## plugin-dropbox

### List: `kestra://` URI provided as a string is not resolved

**Summary**
`List` advertises reading the path from a `kestra://` URI, but only handles a `java.net.URI` object — a YAML-authored `kestra://...` string is used verbatim as the Dropbox path.

**Location** — `src/main/java/io/kestra/plugin/dropbox/files/List.java`
- `run()` (~L111-121): `if (from instanceof String) { rPath = render(from) }` (literal) `else if (from instanceof URI) { read from storage }`.
- Sibling tasks (Move/Search/GetMetadata/CreateFolder/Download/Upload) use a `renderPath()` helper that detects the `kestra://` string prefix and reads storage.

**Impact**
The documented "path from a `kestra://` URI" behavior is unreachable from YAML (YAML values deserialize to `String`, never `URI`), so `List` silently treats the URI as a literal path.

**Suggested fix**
Detect a `kestra://` string prefix in `List` the same way the sibling tasks do (via `renderPath()`), or drop the capability.

---

### GetMetadata: `includeMediaInfo` has no observable effect

**Summary**
`includeMediaInfo` is passed to the Dropbox API but the requested media info is never surfaced in the task output.

**Location** — `src/main/java/io/kestra/plugin/dropbox/files/GetMetadata.java`
- `withIncludeMediaInfo(rIncludeMediaInfo)` (~L92).
- Output only exposes a `DropboxFile` (~L154-157), which has no media-info fields.

**Impact**
Setting `includeMediaInfo: true` changes nothing the user can see.

**Suggested fix**
Either surface media info in the output (extend the output model) or remove the property.

---

### Download: documented leading-slash path check is not enforced

**Summary**
`Download`'s schema says the path "Must start with `/`", but `run()` never checks it (its siblings do).

**Location** — `src/main/java/io/kestra/plugin/dropbox/files/Download.java`
- `from` `@Schema` states "Must start with `/`" (~L87); class desc repeats it (~L75).
- `run()` validates `rPath.isBlank()` (~L116) but not `rPath.startsWith("/")` — unlike Copy/CreateFolder/Delete/GetMetadata.

**Impact**
Inconsistent validation; a malformed path reaches the Dropbox SDK and fails with a less actionable error.

**Suggested fix**
Add the leading-slash check to match the sibling tasks and the documented contract.

# plugin-dropbox — reproduction flows

Prereqs: a Kestra instance with plugin-dropbox installed and a `DROPBOX_ACCESS_TOKEN`
secret on a throwaway Dropbox account. Findings 1 and 2 are also proven without a token
by the unit tests on branch `verify/dropbox-doc-review-bugs`
(`src/test/java/io/kestra/plugin/dropbox/files/DocReviewBugVerificationTest.java`).

---

## 1. `List` does not resolve a `kestra://` URI supplied as a string

`List.from`'s schema/description says the path can come from a `kestra://` URI, but `run()`
only reads storage when `from` is a `java.net.URI` *object*; a `kestra://…` **string**
(the normal YAML case) is used verbatim as the Dropbox path.

```yaml
id: dropbox_list_uri_repro
namespace: company.team

tasks:
# Put the REAL Dropbox path into internal storage (must be an existing Dropbox folder).
- id: make_path_file
type: io.kestra.plugin.core.storage.Write
content: "/RealFolder"

# Per the docs, passing the kestra:// URI should list "/RealFolder".
- id: list
type: io.kestra.plugin.dropbox.files.List
accessToken: "{{ secret('DROPBOX_ACCESS_TOKEN') }}"
from: "{{ outputs.make_path_file.uri }}" # renders to a kestra://... STRING
fetchType: FETCH
```

- **Expected:** lists the contents of `/RealFolder`.
- **Actual:** the Dropbox API is called with the literal `kestra://…/path.txt` string as the
path → `path/not_found` (or malformed-path) error; the URI is never resolved.
- **Contrast:** `Move`, `Search`, `Download`, `Delete`, etc. resolve a `kestra://` string via a
`renderPath()` helper — only `List` uses `instanceof URI`.

---

## 2. `Download` does not enforce the leading-slash contract it documents

`Download.from`'s schema says "Must start with `/`", but `run()` never checks it (its siblings
do). A path without a leading slash is passed straight to the SDK.

```yaml
id: dropbox_download_noslash_repro
namespace: company.team

tasks:
- id: download
type: io.kestra.plugin.dropbox.files.Download
accessToken: "{{ secret('DROPBOX_ACCESS_TOKEN') }}"
from: "data/file.txt" # no leading slash — contrary to the documented contract
```

Contrast — same bad input on a sibling that DOES validate:

```yaml
id: dropbox_getmetadata_noslash_contrast
namespace: company.team

tasks:
- id: metadata
type: io.kestra.plugin.dropbox.files.GetMetadata
accessToken: "{{ secret('DROPBOX_ACCESS_TOKEN') }}"
path: "data/file.txt" # same bad input
```

- **Expected (both):** fail fast with a clear `'from'/'path' path must start with '/'` error.
- **Actual:** `GetMetadata` throws that clear validation error before any API call; `Download`
does **not** validate and sends the un-prefixed path to Dropbox, yielding a less actionable
SDK error.

---

## 3. `GetMetadata.includeMediaInfo` has no observable effect

`includeMediaInfo` is forwarded to the Dropbox API, but the task output (`DropboxFile`) has no
media-info fields, so setting it changes nothing the user can see.

```yaml
id: dropbox_getmetadata_mediainfo_repro
namespace: company.team

tasks:
- id: metadata_plain
type: io.kestra.plugin.dropbox.files.GetMetadata
accessToken: "{{ secret('DROPBOX_ACCESS_TOKEN') }}"
path: "/photos/example.jpg" # an image, so Dropbox has media info for it

- id: metadata_with_media
type: io.kestra.plugin.dropbox.files.GetMetadata
accessToken: "{{ secret('DROPBOX_ACCESS_TOKEN') }}"
path: "/photos/example.jpg"
includeMediaInfo: true
```

- **Expected:** `metadata_with_media` exposes media info (e.g. image dimensions / time taken).
- **Actual:** both outputs are identical `DropboxFile` objects (`name`, `id`, `path`, `type`,
`size`, `clientModified`) — there is no field to carry media info, so `includeMediaInfo` is a
no-op from the user's perspective.

### Environment

- Kestra Version: develop

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with src/main/java/io/kestra/plugin/dropbox/files/List.java, GetMetadata.java, and Download.java, then read the sibling tasks that already resolve paths or validate leading slashes. Run src/test/java/io/kestra/plugin/dropbox/files/DocReviewBugVerificationTest.java first. Done means the documented URI and path behaviors work consistently and includeMediaInfo either appears in output or is removed as specified by the final decision.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
67/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.