Failing to update a task twice in a row

muety commented 3 years ago

Steps to reproduce

Create a new task
Edit its description to "Foo"
Wait for it being saved
Edit its description to "Bar"
Wait for it being saved

Expected behaviour

Task is updated two times.

Actual behaviour

Task is not updated the second time. Server replies with a 412 Precondition Failed and the following error message.

<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
  <s:exception>Sabre\DAV\Exception\PreconditionFailed</s:exception>
  <s:message>An If-Match header was specified, but none of the specified ETags matched.</s:message>
  <s:header>If-Match</s:header>
</d:error>

Server configuration

Nextcloud version: nextcloud:19 Docker image

Tasks version: 0.13.3

Integrity:

No errors have been found.

List of activated apps:

Enabled:
  - cloud_federation_api: 1.2.0
  - contactsinteraction: 1.0.0
  - dav: 1.15.0
  - encryption: 2.7.0
  - federatedfilesharing: 1.9.0
  - files: 1.14.0
  - files_external: 1.10.0
  - files_pdfviewer: 1.8.0
  - files_rightclick: 0.16.0
  - files_sharing: 1.11.0
  - files_versions: 1.12.0
  - files_videoplayer: 1.8.0
  - logreader: 2.4.0
  - lookup_server_connector: 1.7.0
  - notes: 3.6.1
  - notifications: 2.7.0
  - oauth2: 1.7.0
  - password_policy: 1.9.1
  - photos: 1.1.0
  - privacy: 1.3.0
  - provisioning_api: 1.9.0
  - recommendations: 0.7.0
  - serverinfo: 1.9.0
  - settings: 1.1.0
  - survey_client: 1.7.0
  - tasks: 0.13.3
  - text: 3.0.1
  - theming: 1.10.0
  - twofactor_backupcodes: 1.8.0
  - twofactor_totp: 4.1.3
  - updatenotification: 1.9.0
  - viewer: 1.3.0
  - workflowengine: 2.1.0

Nextcloud configuration:

{
    "system": {
        "htaccess.RewriteBase": "\/",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "apps_paths": [
            {
                "path": "\/var\/www\/html\/apps",
                "url": "\/apps",
                "writable": false
            },
            {
                "path": "\/var\/www\/html\/custom_apps",
                "url": "\/custom_apps",
                "writable": true
            }
        ],
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "cloud.muetsch.io"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "19.0.1.1",
        "overwrite.cli.url": "https:\/\/cloud.muetsch.io",
        "installed": true,
        "theme": "",
        "loglevel": 2,
        "maintenance": false,
        "twofactor_enforced": "false",
        "twofactor_enforced_groups": [],
        "twofactor_enforced_excluded_groups": [],
        "mysql.utf8mb4": true,
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "updater.release.channel": "beta"
    }
}

Are you using external storage, if yes which one: no

Are you using encryption: yes

Are you using an external user-backend, if yes which one: no

Client configuration

Browser: Firefox 81.0

Operating system: Ubuntu 20.04

Browser log

See above

raimund-schluessler commented 3 years ago

This is very likely a configuration issue of your server, probably similar to #266. Maybe a reverse proxy strips of the etag. Without it, Tasks won't work (Calendar and Contacts won't work either).

muety commented 3 years ago

I don't think the reverse proxy strips ETags. Please see the following request / response pairs.

As can be seen, the oc-etag header is present in the first response, but not in the second. Also, the format of the requests' If-Match values seems to vary among the two requests.

Could you please try to investigate?

raimund-schluessler commented 3 years ago

Well, I can't investigate much here, since it works fine both on my testing as well as my production server.

Could you check in the database after your requests which would be the correct Etags?

raimund-schluessler commented 3 years ago

Also, in the first response of the server, the format of the etag and oc-etag is different. This shouldn't be. So it looks like a server issue to me.

muety commented 3 years ago

Also, in the first response of the server, the format of the etag and oc-etag is different. This shouldn't be. So it looks like a server issue to me.

It most likely is a server issue, but none of the reverse proxy, since it wouldn't randomly modify ETags.

nextcloud / tasks