tanishqgandhi1908 opened a new pull request, #7142:
URL: https://github.com/apache/texera/pull/7142
### What changes were proposed in this PR?
The multipart upload engine was welded into DatasetService. The model upload
UI (#6499) needs the same engine, and copying it would have duplicated all of
that.
It now lives in MultipartUploadService, parameterized by a small
FileResourceEndpoint ({ baseUrl, nameParamKey }), since the dataset and model
endpoint families differ only in base path and in the query-param name carrying
the resource. DatasetService keeps all four methods with byte-identical
signatures as one-line delegates and re-exports MultipartUploadProgress, so no
caller changes.
FilesUploaderComponent is generalized rather than forked. It takes
resourceName/resourceId (renamed from datasetName/did) plus an endpoint input
defaulting to the dataset one, so its single call site changes three bindings.
No behavioural change. Abort/teardown, resume, retry and the progress/ETA
arithmetic all already existed and are moved verbatim — this PR adds no upload
behaviour, only relocates it. Production code is net-negative: −300 from
DatasetService, +404 in the new service and endpoint config.
One latent bug fixed along the way. multipartUpload builds the per-part URL
by hand rather than through HttpParams, and that string hardcoded
&datasetName=. Parameterizing only the HttpParams call sites would have left
the part upload sending datasetName for every resource — correct for datasets,
and a 400 "Model not found" the moment a model used it, since
/model/multipart-upload/part expects modelName. Both addressing paths now go
through endpoint.nameParamKey.
### Any related issues, documentation, discussions?
Part of #6494. Preparation for the upload half of #6499 — this is the shared
engine that PR consumes.
### How was this PR tested?
The correctness claim is that four pre-existing specs pass with no assertion
changes. The uploader spec's changes are mock rewiring only — it constructs the
component positionally and asserts banner state and emitted items, never call
arguments.
The engine previously had no direct test — only indirect coverage through
DatasetService's public surface. It now has multipart-upload.service.spec.ts
with 13 cases: the endpoint seam via a synthetic { baseUrl: "widget",
nameParamKey: "widgetName" } endpoint; init → part → finish addressing; resume
from missingParts; non-2xx and transport-level part failures; unsubscribe →
abort; auth header present and absent; null-payload tolerance; and the
double-encoding convention on filePath (pre-encoded for HttpParams, encoded
once for the hand-built part URL).
That synthetic endpoint is what catches the hardcoded-param bug above —
verified by mutation: reintroducing it fails exactly one test and nothing else.
cd frontend && npx ng test --watch=false --include
src/app/dashboard/service/user/file-resource/multipart-upload.service.spec.ts
203 tests pass across the seven affected spec files. tsc --noEmit, eslint
and prettier are clean.
Manually verified against a local stack, uploading into a dataset:
single-part and multi-part uploads (a 55 MiB file across two 50 MiB chunks),
version creation, a dragged folder preserving nested paths
(churn-predictor/tokenizer/vocab.txt), the "Matching File Found" conflict modal
for an already-committed file, cancelling an in-flight upload, and staging then
finalizing a file deletion.
<img width="2000" height="1011" alt="image"
src="https://github.com/user-attachments/assets/f927c3c8-0832-4123-978a-f4ccc3e4916a"
/>
<img width="2000" height="965" alt="image"
src="https://github.com/user-attachments/assets/0757e76a-00b9-470e-a532-ed2e652abab8"
/>
### Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Claude Opus 5)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]