Error when deploying - PayloadTooLargeError: request entity too large

I just copied a flow of around 300 nodes to a new tab to start working on some changes, but cannot deploy (any type of deploy) due to the following error. Any ideas for possible debugging ?

PayloadTooLargeError: request entity too large
    at readStream (/usr/lib/node_modules/node-red/node_modules/body-parser/node_modules/raw-body/index.js:163:17)
    at getRawBody (/usr/lib/node_modules/node-red/node_modules/body-parser/node_modules/raw-body/index.js:116:12)
    at read (/usr/lib/node_modules/node-red/node_modules/body-parser/lib/read.js:79:3)
    at jsonParser (/usr/lib/node_modules/node-red/node_modules/body-parser/lib/types/json.js:138:5)
    at Layer.handle [as handle_request] (/usr/lib/node_modules/node-red/node_modules/express/lib/router/layer.js:95:5)
    at trim_prefix (/usr/lib/node_modules/node-red/node_modules/express/lib/router/index.js:328:13)
    at /usr/lib/node_modules/node-red/node_modules/express/lib/router/index.js:286:9
    at Function.process_params (/usr/lib/node_modules/node-red/node_modules/express/lib/router/index.js:346:12)
    at next (/usr/lib/node_modules/node-red/node_modules/express/lib/router/index.js:280:10)
    at cors (/usr/lib/node_modules/node-red/node_modules/cors/lib/index.js:188:7)
    at /usr/lib/node_modules/node-red/node_modules/cors/lib/index.js:224:17
    at originCallback (/usr/lib/node_modules/node-red/node_modules/cors/lib/index.js:214:15)
    at /usr/lib/node_modules/node-red/node_modules/cors/lib/index.js:219:13
    at optionsCallback (/usr/lib/node_modules/node-red/node_modules/cors/lib/index.js:199:9)
    at corsMiddleware (/usr/lib/node_modules/node-red/node_modules/cors/lib/index.js:204:7)
    at Layer.handle [as handle_request] (/usr/lib/node_modules/node-red/node_modules/express/lib/router/layer.js:95:5)
    at trim_prefix (/usr/lib/node_modules/node-red/node_modules/express/lib/router/index.js:328:13)
    at /usr/lib/node_modules/node-red/node_modules/express/lib/router/index.js:286:9
    at Function.process_params (/usr/lib/node_modules/node-red/node_modules/express/lib/router/index.js:346:12)
    at next (/usr/lib/node_modules/node-red/node_modules/express/lib/router/index.js:280:10)
    at expressInit (/usr/lib/node_modules/node-red/node_modules/express/lib/middleware/init.js:40:5)
    at Layer.handle [as handle_request] (/usr/lib/node_modules/node-red/node_modules/express/lib/router/layer.js:95:5)
    at trim_prefix (/usr/lib/node_modules/node-red/node_modules/express/lib/router/index.js:328:13)
    at /usr/lib/node_modules/node-red/node_modules/express/lib/router/index.js:286:9
    at Function.process_params (/usr/lib/node_modules/node-red/node_modules/express/lib/router/index.js:346:12)
    at next (/usr/lib/node_modules/node-red/node_modules/express/lib/router/index.js:280:10)
    at query (/usr/lib/node_modules/node-red/node_modules/express/lib/middleware/query.js:45:5)
    at Layer.handle [as handle_request] (/usr/lib/node_modules/node-red/node_modules/express/lib/router/layer.js:95:5)

Dunno, perhaps this in the settings:

    /** The maximum size of HTTP request that will be accepted by the runtime api.
     * Default: 5mb
     */
    apiMaxLength: '100mb',
1 Like

you can try increasing apiMaxLength in settings.js

1 Like

great minds and all that ... :wink:

Had a look through my settings and found nothing else that might be appropriate - there is a debug limit but that's not what matters.

I vaguely remembering having the same/similar issue and setting the apiMaxLength to fix it ...

Thanks that did the trick, I'm surprised I have not had this issue before, but you live and learn :wink:
I set it to 15mb not sure what implications there are if it is "too" big ?

You beat me to it :grinning_face_with_smiling_eyes:

There is another msg size parameter, maxHttpBufferSize, which is specific to dashboard-2, determining the the max size of messages coming from dashboard widgets

Thanks again both, but as @gregorius exceeded the expected KPI, he gets the tick :rofl:

1 Like

I use a limit of 100MB, and never had an issue except that it takes time to load or deploy flows.

Instead of increasing the message size limit, I would try to reduce the flow size (which will also make it more maintainable). For example, use link-call groups instead of subflows (subflows are actually "macros" which get replicated exponentially: 10 instances of a subflow of 20 nodes, create 200 nodes etc.)

1 Like

It is a bit confusing calling it the runtime api, which tends to make one think it is the flows runtime rather than the admin api.

1 Like