Handle 413 with user friendly message

[etiennejouan]

Add friendly message for 413 errors. Currently, 413 errors originate from the nginx server.

[cubic-dev-ai]

1 issue found across 3 files

Prompt for AI agents (all issues)

Check if these issues are valid — if so, understand the root cause of each and fix them.


<file name="packages/twenty-front/src/modules/apollo/services/__tests__/apollo.factory.test.ts">

<violation number="1" location="packages/twenty-front/src/modules/apollo/services/__tests__/apollo.factory.test.ts:240">
P2: This test can pass without any assertions if makeRequest resolves. Use a rejection assertion (or expect.assertions) so the test fails when the 413 handling isn’t triggered.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

P2: This test can pass without any assertions if makeRequest resolves. Use a rejection assertion (or expect.assertions) so the test fails when the 413 handling isn’t triggered.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At packages/twenty-front/src/modules/apollo/services/__tests__/apollo.factory.test.ts, line 240:

<comment>This test can pass without any assertions if makeRequest resolves. Use a rejection assertion (or expect.assertions) so the test fails when the 413 handling isn’t triggered.</comment>

<file context>
@@ -226,4 +228,21 @@ describe('ApolloFactory', () => {
+      }),
+    );
+
+    try {
+      await makeRequest();
+    } catch (error) {
</file context>

[greptile-apps]

Greptile Overview

Greptile Summary

This PR adds a user-friendly handling path for HTTP 413 (Payload Too Large) errors coming from the upstream proxy by introducing an onPayloadTooLarge callback in ApolloFactory and wiring it to a deduped error snackbar in useApolloFactory. It also adds a unit test to validate that the callback is invoked on a simulated 413 network error.

The change integrates into the existing Apollo link chain by (1) preventing retries for 413 in RetryLink, and (2) intercepting 413s in errorLink before falling back to the existing debug logging and onNetworkError callback.

Confidence Score: 3/5

• This PR is close to mergeable but has a runtime-safety issue in retry error handling that should be fixed first.
• Core 413 handling looks correct and is covered by a unit test, but RetryLink.retryIf calls helpers that assume a ServerError shape; if retryIf receives a non-ServerError value, the code can throw while deciding whether to retry.
• packages/twenty-front/src/modules/apollo/services/apollo.factory.ts

Important Files Changed

Filename	Overview
packages/twenty-front/src/modules/apollo/services/apollo.factory.ts	Adds onPayloadTooLarge option and 413 detection in errorLink/retryIf; current retryIf calls statusCode helpers with untyped errors, which can throw at runtime.
packages/twenty-front/src/modules/apollo/hooks/useApolloFactory.ts	Wires onPayloadTooLarge callback to enqueue a deduped error snackbar; change is straightforward.
packages/twenty-front/src/modules/apollo/services/tests/apollo.factory.test.ts	Adds a test for 413 handling via onPayloadTooLarge callback; test doesn’t assert call count and only asserts substring of message.

Sequence Diagram

sequenceDiagram
  participant UI as Frontend UI
  participant AF as ApolloFactory
  participant RL as RetryLink
  participant EL as ErrorLink
  participant GW as Gateway/Proxy

  UI->>AF: client.mutate/query
  AF->>RL: execute operation
  RL->>GW: HTTP request
  GW-->>RL: 413 Payload Too Large
  RL->>RL: retryIf(error)
  RL-->>EL: propagate networkError
  EL->>AF: isPayloadTooLargeError(networkError)
  AF-->>EL: true
  EL->>UI: onPayloadTooLarge(message)
  UI->>UI: show error snackbar (deduped)

Loading

[greptile-apps]

_{3 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Additional Comments (1)

packages/twenty-front/src/modules/apollo/services/apollo.factory.ts
RetryLink can throw
retryIf passes error straight into isAuthenticationError/isPayloadTooLargeError, but those helpers are typed as ServerError and immediately read error.statusCode (apollo.factory.ts:353-359). In practice RetryLink may provide non-ServerError values (e.g. a plain Error), so this is currently relying on an unsafe type mismatch and can crash if error isn’t an object with statusCode.

Fix by guarding/casting before calling, or by making the helpers accept unknown and checking typeof (error as any)?.statusCode === 'number' before comparing.

[github-actions]

🚀 Preview Environment Ready!

Your preview environment is available at: http://bore.pub:59954

This environment will automatically shut down when the PR is closed or after 5 hours.

[FelixMalfait]

Great!

[twenty-eng-sync]

Hey @etiennejouan! After you've done the QA of your Pull Request, you can mark it as done here. Thank you!

[twenty-eng-sync]

Hey @etiennejouan! After you've done the QA of your Pull Request, you can mark it as done here. Thank you!