NodeOperationError: Unknown input file type.

[JV300381]

Hi,

I am currently trying out the extension.

I have created a simple flow that reads a .docx file and hardcoded the value to be passed to the template in the Cardone node, e.g

{"d.firstname":"JOHN"}

However, it keeps showing the issue below:

Node type: n8n-nodes-carbonejs.carboneNode
Node version: 1 (Latest)
n8n version:1.51.1 (Self Hosted)

Error cause

NodeOperationError: Unknown input file type. It should be a docx, xlsx, pptx, odt, ods, odp, xhtml, html or an xml file at Object.execute

template.docx
demo.json

[jreyesr]

Hello @JV300381! Sorry to hear you're having issues with the node. I had it a long time ago too. I'll take a look in a few hours.

In the meantime, could you please check #1, see if your issue looks the same as that one, and maybe try to use the DOCX file linked there, https://github.com/carboneio/carbone/raw/master/examples/movies.docx? That one comes directly from Carbone. Use {} as the context (or anything, really, it doesn't matter because the error happens before any rendering is performed)

Also, your version of N8N is slightly old. Not too much, they're on 1.58 or so now, and whatever issue I had mysteriously fixed itself before the version that you're running now, but it may have something to do with that, because the way in which binary files are provided to custom nodes such as this one is performed by the core skeleton of N8N. Just as a question, perhaps you may be able to consider upgrading? The folks at N8N release some really cool features fairly frequently (https://github.com/n8n-io/n8n/releases). Otherwise, don't worry, I'll fix this issue on the plugin itself anyways.

Thanks for reporting the issue!

[JV300381]

Hello @jreyesr,

Thank you for taking time to look into the issue.

I have tried the steps you suggested, but without any success.

1/The movies.docx file downloaded has the same issue. As you rightly pointed out, the issue is happening before any rendering is performed. For some reason or another, it doesn't seem to detect the docx file. I have tried over version ODT, Excel. But it seems it is still looking for docx. (Binary property "data" should be a DOCX (Word) file, was application/vnd.oasis.opendocument.text instead or Binary property "data" should be a DOCX (Word) file, was application/vnd.openxmlformats-officedocument.spreadsheetml.sheet instead)

2/I have upgraded my version to 1.58.2 and the issue still persists.

3/I have changed the node option from Render to Convert to PDF, using the same flow as before. This completes successfully but producing a pdf which doesn't make any sense. The docx error doesn't happen in this instance.

template.pdf

[jreyesr]

Hello again! I've made some changes to the node, so that now it hopefully works. This bug is especially nasty because I can't reliably replicate it (I have seen it on one N8N instance that I manage, but not on the development instance where I would be able to test the solution). It works for me™, but it also worked before on this instance, sooo...

If you could test the new version, that'd be much appreciated. To do so, uninstall the Carbone custom node (on http://localhost:5678/settings/community-nodes or the corresponding URL), and then reinstall it, but use n8n-nodes-carbonejs@v1.1.2-bugfix7 as the package name:

It will install an "outdated" version of the plugin, but that's OK. Don't click the Update button, because it'll revert to the version that you have now:

Then, restart your N8N instance (that seems to be important, otherwise you won't see the changes) and try to run your workflow again. Does it work now? Or does it have the same error?

If it still fails, could you please check the N8N logs? If you're launching N8N by running n8n start in a terminal, you should see the logs in that same terminal:

Notice how at the end there are two lines that say content = ... and rendered = .... Please provide them, they're the first raw bytes of the Word template that is being rendered, encoded in Base64. It's OK if you just have the first line, the one with content = ..., because the second one is printed after rendering, which isn't being reached in your case.

[jreyesr]

Oh, by the way, a small comment that is mostly unrelated to this issue. I see that you're setting {"d.firstname":"JOHN"} as the Context field. That isn't required on the Context, you most likely want to pass just {"firstname":"JOHN"} (see the first screenshot in my comment above). Adding d. to the start (e.g. {d.FIELD_NAME}) is Carbone-specific syntax that should only be used on the Word template itself. For example, see Carbone's docs:

What they call Data is our Context, and those fields don't have d.. Only in the Template, which is the Word document, do you need to have {d.SOMETHING}. In other words, within the Word template, {d} refers to the entire Context, and {d.SOMETHING} in the Word document will read the field SOMETHING from the Context.

Just wanted to point that out, since otherwise you'll see blank spaces in the rendered document.

[Vladimir-Va]

Hello, I'm experimenting with the carbone js node and getting an error in the topic.
Is this possible if n8n works in queue mode?

To avoid this, change the N8N_DEFAULT_BINARY_DATA_MODE environment variable to filesystem. This causes n8n to save data to disk, instead of using memory.

If you're using queue mode, keep this to default. n8n doesn't support filesystem mode with queue mode.

[jreyesr]

Hello @Vladimir-Va! I've moved your question to Discussion #8, to keep this issue #7 focused on the NodeOperationError: Unknown input file type. It should be a docx, xlsx, pptx, odt, ods, odp, xhtml, html or an xml file at Object.execute error that was reported originally

[JV300381]

Hi @jreyesr,

Installing the version provided, fixed the issue.
Below is the output as requested:

content = UEsDBBQABgAIAAAAIQDfpNJsWgEAACAFAAATAAgC...
rendered = UEsDBBQAAAgIAJCFMVm8K086TwEAAB8FAAATAAAA...

Thank you for clarifying the Context bit :-)

[jreyesr]

@JV300381 That's great to hear! I think that the node was using an old (older than N8N's v1.0) way of accessing binary data, and that must have become obsolete (though only under certain configurations of N8N) at some point.

I've released v1.1.2, N8N should already be prompting you to update, or it should do it soon:

Please let me know if you find any issues with that version. You shouldn't, since the code is the exactly same as what you've already tested