tus
Passing the context to sync callbacks
In a scenario when tusd is used as library it is most probably integrated into an application having some kind of authentication context attached to the actual tus requests. To access that and to also cancel operations when the client request is cancelled it is necessary to use the request's context in tusd and to pass the context to the callback functions to access these information in the application's domain.
But isn't that behavior wanted. If the client cancels a patch request the underlying store should drop it, too. So the upload offset of an upload would actually be the old offset before the cancelled operation.
But isn't that behavior wanted. If the client cancels a patch request the underlying store should drop it, too. So the upload offset of an upload would actually be the old offset before the cancelled operation.
No that is not what we want. If the upload offset after a PATCH request is the same as before the PATCH request, then no data was stored and the data transfer was useless. If you then try to resume, then you have to start at the previous offset again. A tus server should always try to store as much received data as possible, regardless of whether the PATCH request is completed properly or not. That is how tus implement resumable uploads.
But what about the last PATCH request. If the client cancels the request, it will not get the response anymore by the application's callback. Actually the upload is completed. Can the callback be called by the client if the upload offset pointer stands at the upload length?
If the client cancels the request, it will not get the response anymore by the application's callback
That is correct. That is why the responses for the PATCH requests should not include any critical information that must not be lost. Such information should be relied through another, application-specific system, such as another RESTful endpoint.
I think that is were you misunderstood the principal of using tusd. As in https://github.com/tus/tusd/pull/741, you are sending information in the last response to the client but that is not optimal for failure tolerance.
Can the callback be called by the client if the upload offset pointer stands at the upload length?
No, the callback is only invoked once, when the upload is completed. Never a second time.
Made a change that passes at least the parent context's values but decouples the contexts again: https://github.com/tus/tusd/commit/ab78498b23645d284578c773c6f0473eed0018cd
I wanted to change the godoc of the synchronous callback methods in config.go but unsure how to phrase it correctly because it is contradictory if the callback can be used for validation but it is not guaranteed that the caller ever gets the result.
it is contradictory if the callback can be used for validation but it is not guaranteed that the caller ever gets the result.
I don't understand that. Can you elaborate? Who is the caller? The tus client?
it is contradictory if the callback can be used for validation but it is not guaranteed that the caller ever gets the result.
I don't understand that. Can you elaborate? Who is the caller? The tus client?
right.
Can you explain what the problem with the documentation is then?
the outcome of the validation is crucial to the uploading client. if the connection drops and the request is thus cancelled the client is forced to reupload the file and it will get the outcome after that second upload attempt because the callback is called just once.
Thanks you for your contribution! In tusd v2, the request context will be accessible in the hooks and stores. Please see #986 for more details and #672 for the development of v2.