Storage wrapper in testing app to simulate upload timeout

[PVince81]

To test cases like #32170, one currently needs to patch the OC code to simulate timeouts.

One idea would be to add an extension for the "testing" app to enable random or controlled failures during uploads:

• have oc_appconfig setting for the "testing" app to enable chunk failures
• oc_appconfig setting to specify what chunk indices will have a timeout failure (ex: 1, 5, 8 or none for random)
• the testing app will install a storage wrapper which will, when configured, introduce a timeout in file operations like "fopen" and "file_put_contents"

@DeepDiver1975 @phil-davis @patrickjahns @davitol @butonic

[PVince81]

this could be used to generate deterministic failures in web UI acceptance tests (chunked upload) by setting expected failures on specific chunk ids

[phil-davis]

and @individual-it

[ownclouders]

GitMate.io thinks possibly related issues are #22485 (test), #22492 (test), #31579 (test), #11729 (owncloud app upload issue), and #5163 (No uploads possible - Insufficient storage).

[individual-it]

what about using netem https://wiki.linuxfoundation.org/networking/netem to simulate problematic networks. We could place it in the docker container

[PVince81]

in general it depends whether you want deterministic or non-deterministic tests

in the case of deterministic you'll get exactly the failure you expect
non-deterministic, sometimes tests will pass, sometimes they might not... not ideal for CI

[patrickjahns]

@PVince81
Please consider, that any behavior the testing app can/should change, is doable remotely.

It's about keeping ownCloud as a "blackbox" which we can fortunately alter it's behavior inside to achieve deterministic outcomes. We are moving towards a server <----> client approach. Thus we will need to be able to provide "a client" with a implementation of the server api that can be altered.

@individual-it
netem as simulation is fine for using explorative (manual) testing - or additional explorative testing before/during/after a release. But as vincent said, for certain parts we require deterministic behavior to write stable test suites

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.