Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switching to formdata-node in version 4.0.4 breaks sending large files via ReadableStream #347

Closed
Lunatic174 opened this issue Jan 9, 2025 · 2 comments · Fixed by #348
Closed
Assignees
Labels
bug Indicates a reported issue or malfunction that needs fixing.
Milestone

Comments

@Lunatic174
Copy link

Description:

Starting from version 4.0.4 of jira.js, the library replaced form-data with formdata-node to improve ESM compatibility. The change was introduced as part of #327 to resolve compatibility issues with ESM projects. While this change resolves compatibility issues with ESM projects, it introduces a regression: the inability to upload large files via Node.js ReadableStream without loading the entire file into memory and breaks backward compatibility.

In previous versions (e.g., 3.0.5), form-data allowed seamless usage of ReadableStream for large file uploads. However, formdata-node does not natively support Node.js ReadableStream, and the same code now results in errors when attempting to upload attachments.

Steps to Reproduce:

  1. Upgrade to jira.js version 4.0.4 or higher.
  2. Create a file as a ReadableStream in Node.js.
  3. Attempt to upload the file as an attachment to Jira using the provided API.
  4. Observe that the upload fails with error "Failed to execute 'append' on 'FormData': parameter 2 is not of type 'Blob'."

Example Code:

Code that worked in version 3.0.5:

import { Version3Client } from 'jira.js';
import fs from 'fs';

const client = new Version3Client({
  host: 'https://your-instance.atlassian.net',
  authentication: {
    basic: {
      email: 'your-email@example.com',
      apiToken: 'your-api-token',
    },
  },
});

const fileStream = fs.createReadStream('./large-file.txt');

(async () => {
  try {
    const response = await client.issueAttachments.addAttachment({
      issueIdOrKey: 'PROJECT-123',
      attachment: {
        file: fileStream,
        filename: 'large-file.txt',
      },
    });
    console.log('Attachment uploaded successfully:', response);
  } catch (error) {
    console.error('Error uploading attachment:', error.message);
  }
})();

The same code will fail in 4.0.4 with error "Failed to execute 'append' on 'FormData': parameter 2 is not of type 'Blob'."

Expected Behavior:

Files should be uploaded seamlessly using Node.js ReadableStream, as was possible in version 3.0.5.

Actual Behavior:

Uploads fail when attempting to use Node.js ReadableStream for file attachments. The same code that worked in version 3.0.5 now results in errors.

Environment:

jira.js version: 4.0.4 or later
Node.js version: 20.11.0
OS: macOS Sequoia 15.2

@MrRefactoring MrRefactoring added the bug Indicates a reported issue or malfunction that needs fixing. label Jan 9, 2025
@MrRefactoring MrRefactoring self-assigned this Jan 9, 2025
@MrRefactoring MrRefactoring added this to the v4.0.6 milestone Jan 9, 2025
MrRefactoring added a commit that referenced this issue Jan 9, 2025
* #347: resolve file upload issues with ReadableStream and Readable in Node.js (#348)

* Changelog added for v4.0.6
@MrRefactoring
Copy link
Owner

Fix will be published in v4.0.6. Thank you for the issue

@Lunatic174
Copy link
Author

Thank you for the fix!
I just checked it, and it works now. However, I noticed a potential issue with memory usage because files are uploaded through memory.

I believe this would only be relevant for large files, so I created a separate issue #353 to address it.
Feel free to take a look if you think it's worth discussing further.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Indicates a reported issue or malfunction that needs fixing.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants