Script Rule response - The filename or extension is too long

asked on August 13 • Show version history

I keep getting this error when running my script rule in Cloud. I get the same error through workflow or just using the test option. It seems to happen when I reach a certain amount of characters in the input, Base64Image, but I don't see a character limit here and this would not be a file or extension.

It works if I use a shorter input string

Then as I try a longer input I get the error

Update: So far I have tried different random string sizes and found that I can send a 24,000 character string consistently. So I tried sending 5x <= 24,000 character values but still get the error. There is some file process happening under the hood of Cloud we can not see.

0 0

replied on August 16

Under the hood, the Node.js script is being run by System.Diagnostics.Process and the input tokens are passed as command line arguments. Unfortunately, System.Diagnostics.Process limits the length of the command to 32767 characters, so presumably, your base64-encoded string is longer than around ~32600 characters. I was able to reproduce the issue you're encountering with a normal string that was over 32600 characters long.

Base64 is not a particularly efficient encoding for a file--maybe try compressing the file and encoding it differently before base64-encoding it to be passed as an input parameter? Or you may need an entirely different approach (e.g., retrieving the file via a web request or interacting with the remote agent's file system).

1 0

replied on August 16

From some googling I don't see anything noticeably more efficient than Base64, even Base122 is only 14% smaller so that will not get me down to this size.

Even though I broke the string up into multiple values it still will not let me send more than a total of 32k characters of data total it seems which will never cover the 1 page of information that I need to read.

I tried sending a file to the agent but the type drop down forces a Text type on all script rules and that is why I ended up going with Base64 instead to begin with.

I guess the agent was meant to work with very small chunks of data at a time, not an entire page. I am trying to get images of tables into a simple table and this would have been the most straight forward way to do it but if I crop down to anymore than 1 page, I lose my column names.

Good to know the limit at least.

Here is what it looks like when I try to set the type:

0 0

replied on August 19

Even though I broke the string up into multiple values it still will not let me send more than a total of 32k characters of data total

Correct, and the 32k characters includes other things too, as it's the max length for the command. Multiple input parameters actually just makes it worse as each of those parameters' names takes up some of the character limit.

I tried sending a file to the agent but the type drop down forces a Text type on all script rules and that is why I ended up going with Base64 instead to begin with.

I guess the agent was meant to work with very small chunks of data at a time

Correct, I don't believe this was an intended (or even imagined) use for the input parameters. You'll need to find a different way to retrieve the data from the script (e.g., local file on the remote agent, web request, or LFAPI).

not an entire page

It really has nothing to do with pages, but just with the quantity of data and how efficiently it's encoded.

Out of curiosity, where is this file/data coming from? How are you getting it in base64?

0 0

replied on August 19

It is an image file uploaded to the upload field on a form. Using javascript to convert it to base64 for the workflow input parameter.

This was all a workaround for the fact that script rules only accept text, not images, and the source data is an image file.

The complexity caused by receiving an image of data, rather than just the data itself is mind blowing.

0 0

Question

Question

Script Rule response - The filename or extension is too long

Replies

Sign in to reply to this post.