- var request and var response in Init() → const (never reassigned,
var is function-scoped and hoisted which is undesirable in class methods)
- let formData in UploadChunk() → const (never reassigned)
- chunkResponse in UploadChunk() removed (assigned but never read)
- let start in GetChunks() → const (never reassigned)
- var percent in UpdateProgressBar() → const (never reassigned)
Archive is the local form model used for version/changelog input.
On a new upload Archive.Id is Guid.Empty, so callers received an
empty GUID instead of the real database ID. Pass uploadedArchive.Id,
which is the record fetched from the database after the upload
completes.
If ChunkUploader.Start() threw a JS interop exception Uploading was
left as true permanently, disabling the Upload and Cancel buttons
for the rest of the session without any visible error. Using a
finally block ensures the flag is reset whether the call succeeds,
throws, or is cancelled.
FileMode.Append forces all writes to the end of the file, making
fs.Position assignments ineffective. This works by accident on a
fresh sequential upload but will silently corrupt the file on any
retry, since chunks are re-sent from their original offset but land
at the current end instead. Use FileMode.OpenOrCreate so the seek
to chunk.Start is honoured.
/api/Upload/Init and /api/Upload/Chunk had no authorization policy,
meaning any unauthenticated request could create archive database
records and write arbitrary data to server storage. Every other
endpoint group in the application requires authorization; apply
the same administrator role requirement here.
document.querySelector() can return null if the elements are not
yet in the DOM. Dereferencing null would throw inside the axios
onUploadProgress callback, which is caught by UploadChunk's catch
and re-thrown as a string - causing the whole upload to fail
silently with an undefined message.
UploadChunk throws a template literal string, not an Error object.
Accessing .message on a string primitive returns undefined, so
JSOnUploadError was always called with undefined and the server log
showed no useful detail. Use String(ex) as fallback so the message
is always populated.
The original catch block was simply swalloing errors instead of
propagating them upwards.
When the /api/Upload/Init request failed it set this.Key = null, logged
to the console, and returned normally. From the caller's perspective
Init() had succeeded.
Start() in the Blazor component then called Upload() immediately after,
which proceeded with this.Key = null. Every chunk was sent to the server
with a null key, the server returned 400 for each one, each UploadChunk
call threw, and the whole upload failed - but only after sending every
chunk, and only with the opaque "Error uploading chunk N/M" message
rather than anything pointing at the actual cause.
By removing the catch, an axios error in Init() propagates up through
the JS interop call InvokeVoidAsync("Init", ...) in Start(). That throws
a JSException in C#, Start() exits immediately before Upload() is ever
called, and the finally block resets Uploading so the UI recovers. The
user gets a failure where it actually happened.
