pim.etesync.com new-contact submission ("save" button) has no response; js console shows "422 (Unprocessable Content)" error

[jzacsh]

when I click "save" to submit a new contact form-entry, I see nothing happen on the page. When I try again with js console open I see this:

actions.ts:117
    POST
    https://api.etebase.com/partner/etesync/api/v1/collection/67lB_3nrGMYwIH5kMfcN3HMyYeslJMeW/item/batch/
    422
    (Unprocessable Content)

Both in chrome Version 125.0.6422.141 (Official Build) (64-bit) and in firefox 126.0 (64-bit)

more debug details

I saved a HAR in case it's helpful. Just ping me directly if you need it. Also more JS console output:

more of a dump from JS Console

```js actions.ts:117 POST https://api.etebase.com/partner/etesync/api/v1/collection/67lB_3nrGMYwIH5kMfcN3HMyYeslJMeW/item/batch/ 422 (Unprocessable Content) Etebase.js:2 Uncaught (in promise) Error: 422 [object Object],[object Object] at new n (Etebase.js:2:691582) at n. (createSuper.js:14:24) at new n (Etebase.js:2:691639) at n. (Etebase.js:2:703376) at c (runtime.js:63:40) at Generator._invoke (runtime.js:293:22) at Generator.next (runtime.js:118:21) at n (asyncToGenerator.js:3:20) at A (asyncToGenerator.js:25:9) Etebase.js:2 Uncaught TypeError: input cannot be null or undefined at y (Etebase.js:2:134548) at v (Etebase.js:2:134592) at C (Etebase.js:2:134655) at Object.c [as to_base64] (Etebase.js:2:133099) at Module._ (Etebase.js:2:686911) at construct.ts:96:31 at immutable.es.js:2356:29 at immutable.es.js:2374:16 at Bt.iterate (immutable.es.js:2786:10) at vt.iterate.Ct.iterate (immutable.es.js:2778:22) Etebase.js:2 Uncaught (in promise) TypeError: undefined is not iterable (cannot read property Symbol(Symbol.iterator)) at Function.from () at Q (Etebase.js:2:5574) at e.setBuffer (Etebase.js:2:16149) at Module.Y (Etebase.js:2:25085) at F (Etebase.js:2:687210) at Function.value (Etebase.js:2:700185) at e.value (Etebase.js:2:715538) at etebase-helpers.ts:34:26 at c (runtime.js:63:40) at Generator._invoke (runtime.js:293:22) ```

[tasn]

Whoops. Can you show the actual 422 response? What's the actual error the server returns (shouldn't contain any sensitive information). Additionally, see the request itself (you can redact the sensitive looking "values" of the json, just keep the "keys" so I can see structure).

Once you provide these though I can surely fix it in 5mins.

[jzacsh]

Oh both the payload and response looked like ciphertext to me (and/or encoded content). Do you mind if I just send it to you directly?

(literally no obvious JSON structure: entirely garbled on both ends)

[tasn]

Ohh right, it's msgpack so it would look garbled. Anyhow, the response should be safe to share (you can email it to me if you want) because there shouldn't be anything sensitive there. I can decode it here (it's just msgpack decode).

[jzacsh]

here's the response from the HAR I saved:

        "response": {
          "status": 422,
          "statusText": "",
          "httpVersion": "http/2.0",
          "headers": [
            {
              "name": "access-control-allow-credentials",
              "value": "true"
            },
            {
              "name": "access-control-allow-origin",
              "value": "https://pim.etesync.com"
            },
            {
              "name": "content-length",
              "value": "2763"
            },
            {
              "name": "content-type",
              "value": "application/msgpack"
            },
            {
              "name": "date",
              "value": "Thu, 13 Jun 2024 16:38:11 GMT"
            },
            {
              "name": "server",
              "value": "nginx"
            },
            {
              "name": "vary",
              "value": "Origin, Origin"
            }
          ],
          "cookies": [],
          "content": {
            "size": 2763,
            "mimeType": "application/msgpack",
            "text": "REDACTED by tasn - not sensitive, but still better redacted",
            "encoding": "base64"
          },
          "redirectURL": "",
          "headersSize": -1,
          "bodySize": -1,
          "_transferSize": 2932,
          "_error": null
        },

[jzacsh]

Additionally, see the request itself

Whoops miss this. Just emailed you for this.

[tasn]

I'm pretty sure it's fixed in https://github.com/etesync/server/commit/f35b4b94e5a75bbc8cc41749ca2e3800bbc7a44e

It happened because pydantic v2 changed the behavior in a few ways (for the better fwiw) and I missed a few things when upgrading.

Can you try now? The server should be running the fixed version!

[jzacsh]

confirmed fixed. Thanks for the quick deploy!

[tasn]

Thanks for all of the helpful debug info!