[tests-only][full-ci] added test to resume all uploads sessions #11307
Conversation
a9c520e to
c881d44
Compare
c881d44 to
2e08b69
Compare
| And user "Alice" has created a new TUS resource in the space "Personal" with 8000 the following headers: | ||
| | Upload-Length | 10 | | ||
| # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt | ||
| | Upload-Metadata | filename dGV4dEZpbGUudHh0 | | ||
| | Tus-Resumable | 1.0.0 | | ||
| And user "Alice" has uploaded file with checksum "SHA1 8cb2237d0679ca88db6464eac60da96345513964" to the last created TUS Location with offset "0" and content "12345" via TUS inside of the space "Personal" using the WebDAV API |
There was a problem hiding this comment.
any use of using tus
There was a problem hiding this comment.
This will make the upload post processing state false.
There was a problem hiding this comment.
as per my understanding resume should start uploading from the point where the upload has corrupt/unfinish. Above step upload Upload-Length of 5 out of 10 but we never send remaining 5 then how would ocis resume upload?
| @issue-11290 | ||
| Scenario: resume all uploads sessions | ||
| Given the config "POSTPROCESSING_DELAY" has been set to "10s" | ||
| And user "Alice" has created a new TUS resource in the space "Personal" with the following headers: |
There was a problem hiding this comment.
what make this scenario full proof that we have unfinish upload in every run
There was a problem hiding this comment.
There is test coverage to clean upload sessions that are not in post-processing processing=false with similar step. This proves the upload is unfinished.
There was a problem hiding this comment.
could you try this below tests case manually and see whether resume command works or not
- Given the config "POSTPROCESSING_DELAY" has been set to "10s"
- upload resources
- stop ocis server
- list upload session
./ocis/bin/ocis storage-users uploads sessions - try to do resume
./ocis/bin/ocis storage-users uploads sessions --resume
There was a problem hiding this comment.
could you try this below tests case manually and see whether resume command works or not
- Given the config "POSTPROCESSING_DELAY" has been set to "10s"
- upload resources
- stop ocis server
- list upload session
./ocis/bin/ocis storage-users uploads sessions- try to do resume
./ocis/bin/ocis storage-users uploads sessions --resume
with this steps ./ocis/bin/ocis storage-users uploads sessions returns the upload sessions with processing status true.
Sessions:
+--------------------------------------+--------------------------------------+---------------------+--------+--------+--------------------------------------+--------------------------------------+---------------------------+------------+----------------------+-------------+
| Space | Upload Id | Name | Offset | Size | Executant | Owner | Expires | Processing | Scan Date | Scan Result |
+--------------------------------------+--------------------------------------+---------------------+--------+--------+--------------------------------------+--------------------------------------+---------------------------+------------+----------------------+-------------+
| 82313778-1e3c-4fb4-a391-543567e57897 | 9c028320-7338-4079-9eb9-5e53b91c8c60 | image-annotated.png | 107705 | 107705 | 82313778-1e3c-4fb4-a391-543567e57897 | 82313778-1e3c-4fb4-a391-543567e57897 | 2025-05-15T11:52:51+05:45 | true | 0001-01-01T00:00:00Z | |
+--------------------------------------+--------------------------------------+---------------------+--------+--------+--------------------------------------+--------------------------------------+---------------------------+------------+----------------------+-------------+
But, for our test case, the status of processing matters or not?
As of my understanding, for processing=true the --resume command does not make sense as the upload is already in processing state whereas processing=false means the upload process is paused or stopped and --resume flag will continue from the point where it was paused or stopped.
So, I tried to get the upload processing status False. With stopping and restarting the ocis server I couldn't get the upload processing status false. Only possible way was with TUS upload similar to the scenario mentioned in above comment.
As you mentioned in the comment #11307 (comment), that's a valid point. We should think of an alternative step.
The --resume command in every case returns the same error:
Sessions:
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0xfa0d55]
goroutine 1 [running]:
github.com/owncloud/reva/v2/pkg/events.Publish({0x53ac660, 0x757f260}, {0x0, 0x0}, {0x350dd00, 0xc001e24ba0})
/home/prajwol/www/ocis/vendor/github.com/owncloud/reva/v2/pkg/events/events.go:156 +0x3f5
github.com/owncloud/ocis/v2/services/storage-users/pkg/command.ListUploadSessions.func2(0xc001d92c80)
/home/prajwol/www/ocis/services/storage-users/pkg/command/uploads.go:209 +0x10f2
github.com/urfave/cli/v2.(*Command).Run(0xc001b77b80, 0xc001d92c80, {0xc001e1a8c0, 0x2, 0x2})
/home/prajwol/www/ocis/vendor/github.com/urfave/cli/v2/command.go:276 +0x7be
github.com/urfave/cli/v2.(*Command).Run(0xc001b78000, 0xc001d92bc0, {0xc001da5aa0, 0x3, 0x3})
/home/prajwol/www/ocis/vendor/github.com/urfave/cli/v2/command.go:269 +0xa45
github.com/urfave/cli/v2.(*Command).Run(0xc001b78b00, 0xc001b90200, {0xc001b90240, 0x4, 0x4})
/home/prajwol/www/ocis/vendor/github.com/urfave/cli/v2/command.go:269 +0xa45
github.com/urfave/cli/v2.(*Command).Run(0xc001b98160, 0xc001b90100, {0xc000050050, 0x5, 0x5})
/home/prajwol/www/ocis/vendor/github.com/urfave/cli/v2/command.go:269 +0xa45
github.com/urfave/cli/v2.(*App).RunContext(0xc00191f600, {0x53acd38, 0xc001b08fc0}, {0xc000050050, 0x5, 0x5})
/home/prajwol/www/ocis/vendor/github.com/urfave/cli/v2/app.go:333 +0x5a5
github.com/owncloud/ocis/v2/ocis/pkg/command.Execute()
/home/prajwol/www/ocis/ocis/pkg/command/root.go:32 +0x1ea
main.main()
/home/prajwol/www/ocis/ocis/cmd/ocis/main.go:11 +0x13
There was a problem hiding this comment.
The --resume command in every case returns the same error:
@PrajwolAmatya that's new because when i opened QA ticket it was working for test case i metioned
There was a problem hiding this comment.
Processing true means the upload process is ongoing and the upload will be successful after the time set in POSTPROCESSING_DELAY env.
Whereas, processing false means that the upload process failed and the file will not be uploaded.
IMO, processing matters because what's the point of resuming the upload that is already in the process. But with the failed upload resume should start from the point where the upload failed.
Doc: https://owncloud.dev/services/postprocessing/#resume-postprocessing
There was a problem hiding this comment.
please check manual whether having processing=true, auto finish their upload or not for this scenario
Given the config "POSTPROCESSING_DELAY" has been set to "10s"
upload resources
stop ocis server
list upload session ./ocis/bin/ocis storage-users uploads sessions
restart ocis
wait for 10s and see wether resource finish its upload or not ?
There was a problem hiding this comment.
please check manual whether having processing=true, auto finish their upload or not for this scenario
Given the config "POSTPROCESSING_DELAY" has been set to "10s"
upload resources
stop ocis server
list upload session ./ocis/bin/ocis storage-users uploads sessions
restart ocis
wait for 10s and see wether resource finish its upload or not ?
The resource don't get uploaded. But the confusing part is the processing value true. Since the upload didn't finish, the processing should be false IMO.
But still I am getting the same error while running the resume command. I will update the scenario and add it to the expected failure file.
There was a problem hiding this comment.
@PrajwolAmatya please confirm with developer what is expected beahvaior
There was a problem hiding this comment.
@amrita-shrestha created an issue for that #11369
2e08b69 to
74064ea
Compare
| And user "Alice" has created a new TUS resource in the space "Personal" with the following headers: | ||
| | Upload-Length | 10 | | ||
| # dGV4dEZpbGUudHh0 is the base64 encode of textFile.txt | ||
| | Upload-Metadata | filename dGV4dEZpbGUudHh0 | | ||
| | Tus-Resumable | 1.0.0 | | ||
| And user "Alice" has uploaded file with checksum "SHA1 8cb2237d0679ca88db6464eac60da96345513964" to the last created TUS Location with offset "0" and content "12345" via TUS inside of the space "Personal" using the WebDAV API |
There was a problem hiding this comment.
as per my understanding resume should start uploading from the point where the upload has corrupt/unfinish. Above step upload Upload-Length of 5 out of 10 but we never send remaining 5 then how would ocis resume upload?
74064ea to
36384f4
Compare
36384f4 to
9fe4c3b
Compare
9fe4c3b to
4223c67
Compare
4223c67 to
b558b5b
Compare
b558b5b to
6b96cba
Compare
65041e6 to
5207ea9
Compare
5207ea9 to
2332035
Compare
|
Description
This PR adds test to resume all the uploads sessions using the CLI command.
While resuming the upload sessions, currently it returns an error, reported in #11290.
Related Issue
Types of changes
Checklist: