Skip to content

Conversation

@joaquincasal
Copy link
Collaborator

Purpose

A customer is having an issue in which the dialog of the app is not displaying correctly due to a "response too big" error.

Approach

We've introduced some optimizations so requests made by the app have a smaller response size:

  • Separate entries and assets referenced in the published and current field, so responses are smaller. This also speeds up the search that happens later in the createOptions method
  • When fetching assets, use the select paramester to only retrieve the title, which is the only thing that gets used
  • Add the include: 0 parameter when using entry.getPublished since by default the response includes an include array that is not used

@joaquincasal joaquincasal requested a review from a team as a code owner December 12, 2025 17:13
Copy link
Collaborator

@FBanfi FBanfi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! 💯 🚀

});
return fetchedAssets.items;
} catch (error) {
console.error('Error fetching assets:', error);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💭 should we notify users? So they know that something went wrong. Also in the getEntries and the content type fetch?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're already doing that 😎 In the createOptions function if we can't identify the entry, asset or content type we just display it as unknown. This just logs the specific error in the console to be able to debug

Copy link
Collaborator

@JuliRossi JuliRossi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Left some questions

name: 'Fruits',
sys: { id: 'fruits' },
fields: [{ id: 'title', name: 'Title', type: 'Symbol' }],
mockSdk.cma.contentType.getMany = vi.fn().mockResolvedValue({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider adding a test to trigger the response too big error and see if the app handles it appropriately. Although this PR optimizes to avoid this situation with the updated querying it might also be worth thinking about how it might fail even with these optimizations

Copy link
Contributor

@ryunsong-contentful ryunsong-contentful left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Certainly an improvement and probably would fix the customer issue, but it's still possible to get a response too big error. So probably worth adding a test to see what happens when it still gets that error and maybe come up with a creative solution around the worst case still.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants