Form submission causes 413 error in UI

Does anyone know exactly what is included in the payload when Forge makes a graphql call prior to the form submit callback?

My app has a a form, which upon submission is throwing a 413:

{
    "timestamp": 1690920931636,
    "path": "/central/graphql",
    "status": 413,
    "error": "Payload Too Large",
    "message": "GraphQl query and variables must not exceed 512000 bytes in size",
    "requestId": "061700d0-7918838",
    "exception": "io.atlassian.graphql.gateway.http.request.RequestTooLargeException",
    "request_id": "UNKNOWN",
    "query": "unknown",
    "operation": "unspecified",
    "schema": "unspecified",
    "errorSource": "GRAPHQL_GATEWAY"
}

However, the submit callback is never invoked, so it is extremely difficult to debug this “behind the scenes” error - and it’s not evident anywhere in the documentation.

What appears to be happening is Forge is making this graphql call with ALL component state data - which again, is extremely confusing. Can anyone clear this up for me? A simplified code example is below:

import ForgeUI, { render, Fragment, Form, Select, Option, useState } from '@forge/ui';

const App = () => {
  const [someState, setSomeState] = useState(null); // This non-form data seems to affect payload size???

  const onSubmit = async (formData) => {
    // this callback is never called, 413 error is shown in UI to users instead
  }

  return (
    <Fragment>
        <Form onSubmit={onSubmit} submitButtonText="Submit">
          <Select label="Options" name="options">
            <Option label="Option" value="option" />
          </Select>
        </Form>
    </Fragment>
  );
};

export const run = render(
  <App />
);

Thanks,
Scott

Hey @ScottB,

this has to do with the way UI Kit works. Instead of running in the browser, the whole state is sent via GraphQL, the new UI state is computed in a Lambda function on Atlassian servers and the whole state is sent back to the browser to be displayed.
If you are dealing with too ‘large’ data-sets the whole app crashes and you can’t contain the error. For us, this meant reducing the amount of data we handle as state i.e. setting hard-coded limits for the number of Issues we retrieve and reducing the number of fields as much as possible.

Here you can find some people who are facing the same problem.

This most likely will be solved with UI Kit 2, since the state is handled in the browser then.
Alternatively you could also use Custom UI.

1 Like

Hi @CPS,
Thank you for the context and clarification. This is unfortunate that Atlassian does not specify this anywhere in their documentation (that I found). We don’t use large datasets, but it just so happened the number of Select options and their label text had pushed the size to just over 500kB. A half meg memory restriction feels like we’re living in the 80s lol.