zendesk_api gem pins Faraday below 2.0, blocking Faraday 2.x upgrades

Not specified by the original author.

TL;DR

The pin existed because the middleware changes in Faraday 2 were non-trivial for this gem, but the maintainers picked it up and released v1.38.0.rc1, a release candidate with Faraday 2 support.

Steps

1. Faraday 2.x is out, but the zendesk_api gemspec pins Faraday to < 2.0.0. I am using Faraday elsewhere in my app and need to upgrade everything to Faraday 2 - the Zendesk gem is blocking me. Is Faraday 2.x support planned?
2. Yes, Faraday 2.x support shipped. The pin existed because the middleware changes in Faraday 2 were non-trivial for this gem, but the maintainers picked it up and released v1.38.0.rc1, a release candidate with Faraday 2 support. So if Faraday 2 is blocking your bundle, update to v1.38.0.rc1 or a newer release that carries the support.

When to use

You are seeing this: Faraday 2.x is out, but the zendeskapi gemspec pins Faraday to < 2.0.0. Use this skill when you run into "zendeskapi gem pins Faraday below 2.0, blocking Faraday 2.x upgrades".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: 2.0.0, v1.38.0. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Asked in the thread (https://vectle.com/threads/thrqMwPcNxs7Sqv0psU1cX7kg): Faraday 2.x is out, but the zendeskapi gemspec pins Faraday to < 2.0.0. I am using Faraday elsewhere in my app and need to upgrade everything to Faraday 2 - the Zendesk gem is blocking me. Is Faraday 2.x support planned? The verified answer: Yes, Faraday 2.x support shipped. The pin existed because the middleware changes in Faraday 2 were non-trivial for this gem, but the maintainers picked it up and released v1.38.0.rc1, a release candidate with Faraday 2 support. So if Faraday 2 is blocking your bundle, update to v1.38.0.rc1 or a newer release that carries the support.

Source: https://github.com/zendesk/zendeskapiclientrb/issues/488 Thread: https://vectle.com/threads/thrqMwPcNxs7Sqv0psU1cX7kg

Not specified by the original author.

TL;DR

For "NoMethodError: undefined method 'key?' for #[Faraday::Multipart::CompositeReadIO]": we updated zendeskapi from 1.26 to 1.38.0.rc1 because other dependencies required Faraday >= 2.0. The workaround is to use \id suffixed attributes (send ids only, not whole objects) when you have existing records, since the gem is not exactly like ActiveRecord.

NoMethodError: undefined method 'key?' for #[Faraday::Multipart::CompositeReadIO]

Steps

1. We updated zendeskapi from 1.26 to 1.38.0.rc1 because other dependencies required Faraday >= 2.0. Now, for under 10% of our tickets, we get: NoMethodError: undefined method 'key?' for #[Faraday::Multipart::CompositeReadIO] coming from `zendeskapi/middleware/request/upload.rb in set_file`. It only happens in production and I cannot reproduce it locally. What causes this?
2. This was a real bug in the rc1 release. It triggered when the request payload was large: users whose ticket payloads carried extra data like thumbnail references got a Faraday::Multipart::CompositeReadIO instance passed to the upload middleware's set_file, which called key? on it and crashed. The workaround is to use _id suffixed attributes (send ids only, not whole objects) when you have existing records, since the gem is not exactly like ActiveRecord. The actual fix was pushed in the rc2 build, which the maintainer confirmed resolves it. So update to a version containing the rc2 fix, or use the _ids workaround if you are pinned to rc1.

Expected: The actual fix was pushed in the rc2 build, which the maintainer confirmed resolves it.

When to use

You are seeing this: Now, for under 10% of our tickets, we get: NoMethodError: undefined method 'key?' for #[Faraday::Multipart::CompositeReadIO] coming from zendesk\api/middleware/request/upload.rb in set\file. Use this skill when you run into "zendesk_api 1.38.0.rc1 crashes with NoMethodError: undefined method 'key?' on multipart uploads".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: zendesk_api 1.38.0. If you are on something much newer or older, the details may have shifted.

Why this happens

We updated zendesk_api from 1.26 to 1.38.0.rc1 because other dependencies required Faraday >= 2.0.

Asked in the thread (https://vectle.com/threads/thrjh13wEB0R0SiGF0b7oZf6g): We updated zendeskapi from 1.26 to 1.38.0.rc1 because other dependencies required Faraday >= 2.0. Now, for under 10% of our tickets, we get: NoMethodError: undefined method 'key?' for #[Faraday::Multipart::CompositeReadIO] coming from zendesk_api/middleware/request/upload.rb in set_file. It only happens in production and I cannot reproduce it locally. What causes this? The verified answer: This was a real bug in the rc1 release. It triggered when the request payload was large: users whose ticket payloads carried extra data like thumbnail references got a Faraday::Multipart::CompositeReadIO instance passed to the upload middleware's set_file, which called key? on it and crashed. The workaround is to use _id suffixed attributes (send ids only, not whole objects) when you have existing records, since the gem is not exactly like ActiveRecord. The actual fix was pushed in the rc2 build, which the maintainer confirmed resolves it. So update to a version containing the rc2 fix, or use the _ids workaround if you are pinned to rc1.

Source: https://github.com/zendesk/zendeskapiclientrb/issues/513 Thread: https://vectle.com/threads/thrjh13wEB0R0SiGF0b7oZf6g

Not specified by the original author.

When a Zendesk file upload fails from the browser, drop the FormData wrapper. POST to the uploads endpoint with the file as the body and the Content-Type header set to the file's MIME type. Zendesk wants the raw bytes with a matching content type, which is also how the curl form works with --data-binary.

Context: Stack Overflow #52751920 (accepted answer, 7 votes): the asker tried to upload a file to the Zendesk uploads endpoint using FormData and it failed. The accepted answer: POST the File object itself as the request body and set the Content-Type header to the file's own type. Zendesk expects the raw binary, not a multipart form.

Matched source

Source: Published skill Original query: "Zendesk uploads: POST the file as the body with its content type, not FormData" Key terms: body, content, file, formdata, post, type, uploads, zendesk

Source: Stack Overflow #52751920 (accepted answer, 7 votes): the asker tried to upload a file to the Zendesk uploads endpoint using FormData and it failed. The accepted answer: POST the File object itself as the request body and set the Content-Type header to the file's own type. Zendesk expects the raw binary, not a multipart form.

Verified resolution: When a Zendesk file upload fails from the browser, drop the FormData wrapper. POST to the uploads endpoint with the file as the body and the Content-Type header set to the file's MIME type. Zendesk wants the raw bytes with a matching content type, which is also how the curl form works with --data-binary.

Source URL: https://stackoverflow.com/questions/52751920/uploading-a-binary-file-using-fetch