docs: cloud data uploads - #3865
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. @@ Coverage Diff @@
## main #3865 +/- ##
==========================================
+ Coverage 77.64% 77.73% +0.08%
==========================================
Files 1323 1325 +2
Lines 125419 125918 +499
Branches 10911 10992 +81
==========================================
+ Hits 97384 97884 +500
+ Misses 24890 24889 -1
Partials 3145 3145
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
Greptile SummaryThis change documents hosted cloud-data workflows and adds related CLI reference entries. Three documented workflows do not match the current command behavior: combining a named path with Confidence Score: 2/5Not safe to merge as documented until the upload-selection, quiet-window exit behavior, and codec-suffix round-trip failures are addressed. Focused executable reproductions confirmed three independent user-facing failures in the documented cloud-data workflows. Files Needing Attention: docs/usage/cli.md and docs/usage/cloud_data.md describe the affected behavior; the corresponding implementation paths are in dimos/cloud/cli.py and dimos/cloud/data.py.
What T-Rex did
|
|
|
||
| | Subcommand | Description | | ||
| |------------|-------------| | ||
| | `upload [PATH\|latest] [--since 1h] [--robot ID] [--kind KIND] [--chunk MB]` | Upload; no argument means the newest recording | |
There was a problem hiding this comment.
Upload selectors silently conflict
The synopsis permits combining a path with --since, but dimos data upload named-path.db --since 1h ignores named-path.db and uploads every recording discovered in the time window instead. Reject this ambiguous combination, or document and implement an explicit precedence that cannot silently discard the user-selected file.
Artifacts
Narrow PATH plus --since reproduction harness
- Authored and executed a minimal in-process harness that feeds the upload handler the parsed equivalent of `dimos data upload named-path.db --since 1h` and records targets, proving the named path is not selected.
Observed PATH plus --since command output
- Captured output of `python trex-artifacts/path-since-priority-02-after.py` from `/home/user/repo`; it shows discovery received 3600 seconds and uploaded unrelated recordings instead of the named path, confirming the claim.
| - Files are compressed before transfer (lz4 by default, see below), sha256-verified server-side, and deduplicated by content: re-uploading the same bytes reports `already uploaded`. | ||
| - Interrupted uploads resume: the server's part listing is the only resume state, so a killed upload re-sends only the missing parts. | ||
| - Recordings carry a manifest: the stream list from `_streams` plus the blueprint name parsed from the `<stamp>-<blueprint>` run directory. `dimos data ls` shows both. | ||
| - Discovery modes (no argument, `--since`) skip files modified within the last `dimos_upload_quiet_s` seconds (default 30) so a store that is still being written is not shipped mid-run. Naming a path or `latest` is explicit intent and uploads immediately. |
There was a problem hiding this comment.
Quiet-window skips fail discovery uploads
A fresh recording found by no-argument or --since discovery is reported as file still being written — skipped, but the command exits with status 1. Handle this expected quiet-window condition as a successful skip so the documented discovery behavior does not make scheduled uploads fail.
Artifacts
Quiet-window discovery reproduction source
- Authored Python harness creates one fresh recording and executes the repository’s data discovery and CLI upload sources with offline-only dependency stubs; the takeaway is that the tested path is narrow and reproducible.
Quiet-window discovery command output
- Captured stdout, stderr, command, working directory, and exit behavior from the `uv run --no-sync` reproduction; the takeaway is that discovery selects the fresh recording and the CLI exits 1.
|
|
||
| Any file type is accepted. Kind is inferred: a mem2 SQLite store (has a `_streams` table) or `.mcap` is a `recording`, anything else a `blob`. Override it with `--kind`. `--robot` tags a robot id, `--chunk` sets the multipart part size in MB. | ||
|
|
||
| - Files are compressed before transfer (lz4 by default, see below), sha256-verified server-side, and deduplicated by content: re-uploading the same bytes reports `already uploaded`. |
There was a problem hiding this comment.
Codec suffix breaks arbitrary-file round trips
An arbitrary non-LZ4 file named artifact.lz4 bypasses compression because of its filename, but is still stored with content_encoding=lz4. Pull then tries to decompress the raw bytes and fails instead of restoring the file byte-identically. Only stamp an encoding when compression occurred, or always stage and compress uploads using the configured codec.
Artifacts
Executable invalid artifact.lz4 round-trip harness
- This isolated in-memory transport invokes the real upload and pull implementation with invalid bytes named artifact.lz4, confirming the target path is exercised.
Captured invalid artifact.lz4 harness source
- This command capture includes the harness SHA-256 and complete executed source so the reproduction inputs and calls are auditable, confirming the exact test setup.
Observed invalid artifact.lz4 upload and pull output
- This successful command capture shows identical raw source and wire hashes, an lz4 encoding stamp, and the LZ4 decode failure with no output file, confirming the documented round trip fails.
There was a problem hiding this comment.
Confirmed; fixing in a draft PR against main (stamp content_encoding only when compression ran, regression test included) — branch fix/codec-stamp.
Usage page for dimos data (upload/ls/pull/status/quota): codec selection with measured ratios, the full GlobalConfig table (flag/env/.env forms), staging and quiet-window behavior. cli.md gains dimos login and dimos data command entries linking to it.