Repository navigation
desktop: gateway cloud endpoints - #4597
jeff-hykin wants to merge 10 commits into
Conversation
…e login in progress), POST/DELETE /cloud/login, and the upload queue at /cloud/uploads
There was a problem hiding this comment.
go2 replay realtime (arm64)
Details
| Benchmark suite | Current: 0ef2daf | Previous: 4bee180 | Ratio |
|---|---|---|---|
peak memory |
1591.965 MB |
1566.871 MB |
1.02 |
peak threads |
359 threads |
364 threads |
0.99 |
network (transport) |
2722.163 MB |
2730.605 MB |
1.00 |
disk write |
1.656 MB |
1.449 MB |
1.14 |
instructions |
115.375 G |
115.402 G |
1.00 |
This comment was automatically generated by workflow using github-action-benchmark.
…) into jeff/feat/gateway_cloud
…feat/gateway_cloud
Codecov Report✅ All modified and coverable lines are covered by tests. @@ Coverage Diff @@
## jeff/feat/dimos_server #4597 +/- ##
==========================================================
- Coverage 81.83% 81.83% -0.01%
==========================================================
Files 1641 1641
Lines 153511 153511
Branches 12933 14459 +1526
==========================================================
- Hits 125628 125623 -5
- Misses 24291 24293 +2
- Partials 3592 3595 +3
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
[Critical impact] Adds cloud upload and authentication to the gateway API. Not safe to merge until authentication cancellation reliably prevents credential persistence and queued uploads; the two upload-history and late-cancellation concerns are non-blocking. Findings
SummaryAdds cloud account and device-login routes, plus a saved upload queue with progress events and upload history.
All three behaviors were reproduced. PR #4506 at its supplied head does not fix them. Reviews (1) · Last reviewed commit: "gateway: the Dimensional cloud endpoints..." · Reviewed by Greptile |
| answer = cloud._post("/auth/token", device_code=device["device_code"]) | ||
| if answer["status"] == "ok": | ||
| cloud._store(answer["api_key"]) | ||
| self.set_login(state="approved", email=answer.get("email")) | ||
| self.account_cache = None | ||
| self.logged_in() |
There was a problem hiding this comment.
Cancelled login still saves credentials
Cancelling a login while /auth/token is still answering does not prevent a successful response from saving credentials. Although the cancellation endpoint returns with the login idle and the gateway logged out, the cancelled thread then marks the login approved and wakes queued uploads. Recordings can therefore upload after the user explicitly cancelled authentication.
This must be fixed before merging. Check that the login attempt is still current before saving credentials or changing shared state, and synchronize that check and those changes with cancellation.
How this was verified: Cancelling an in-flight token request returned a logged-out response, but releasing its successful reply persisted credentials and resumed a queued upload.
Artifacts
Executed isolated login cancellation test
- Loads gateway modules directly from each commit and exercises real routes and workers with controlled token-response barriers, making the cancellation race reproducible without production edits.
Login cancellation before the dependent change
- Executed the race on f08e36c and captured complete HTTP statuses, response bodies, credential persistence, and queue resumption, confirming cancellation is bypassed.
Login cancellation after the dependent change
- Executed the same race on 98f4b33 and captured the same credential persistence and queue resumption after cancellation, confirming the dependent change does not fix it.
Exact source and dependent change comparison
- Captured git diff output, numbered source excerpts, matching affected-file blob IDs, the executed script checksum, and clean tracked-file checks, confirming unchanged vulnerable code and no production modifications.
| found = _size_and_mtime(upload["path"]) | ||
| if upload["state"] != "done" or found is None or not upload.get("uploadId"): | ||
| return None | ||
| return { | ||
| "path": upload["path"], | ||
| "uploadId": upload["uploadId"], | ||
| "size": found[0], | ||
| "mtimeMs": found[1], |
There was a problem hiding this comment.
Changed recordings appear uploaded
If a recording grows after compression while its upload is running, uploaded_entry records the newer local file's size and modification time rather than the version sent to the cloud. checked then reports changed=False even though the cloud copy lacks the new data. This incorrect status persists after restarting the upload manager.
This is a non-blocking upload-history accuracy issue: users cannot rely on the unchanged status to identify recordings that need another upload. Capture and validate the source details for the uploaded snapshot, and preserve those details instead of sampling the source after transfer.
| def tick(phase: str, done: int, total: int) -> None: | ||
| if cancel.is_set(): | ||
| raise CancelledUploadError() | ||
| loop.call_soon_threadsafe(progress, phase, done, total) | ||
|
|
||
| try: | ||
| result = await asyncio.to_thread( | ||
| self._transfer, upload["path"], upload["robotId"], upload["kind"], tick | ||
| ) |
There was a problem hiding this comment.
Upload cancellation stops working
Cancelling an upload only takes effect when tick runs. After the final part, CloudData.upload completes the upload and builds and sends its preview without further progress calls. Cancellation during that work returns success but leaves the single worker occupied; the item eventually becomes done, and later uploads wait until that work finishes.
This is a non-blocking cancellation and queue-responsiveness issue. Pass cancellation through completion and preview work, and check it before recording success.
# Conflicts: # dimos.yaml # experimental/gateway/README.md # experimental/gateway/app.py
The gateway's Dimensional cloud endpoints: /cloud/account, /cloud/login and the /cloud/uploads queue.