Feature(s) impacted
Viewing Table record details
Observed behavior
Seeing Server error as message on the screen
Expected behavior
View the table record details
Failure Logs
Please check your server logs for more information.
I, [2024-01-30T08:30:02.909240 #150] INFO – : [Root=1-65b8b389-6ff2c6e555fc516156182073] [2d8902b8-ec92-4874-a3c7-1db5b2fcc33f] [API] Completed 500 Internal Server Error in 1437ms (ActiveRecord: 78.8ms | MongoDB: 0.0ms | Allocations: 114987)
Context
- Project name: co-lend
- Environment name: production
- Agent (forest package) name & version: 7.6.12(ruby/rails)
- Database type: postgres(RDS)
- Recent changes made on your end if any: A deployment was made with schema changes to DB
One possible issue is, the seelect statement issued is so huge that postgres might be blocking the query claiming it to have too many columns[>1664 entries]
How do we instruct FA to reduce the columns being queried?
Note: The table itself has lesser columns, but Forest Admin is trying to preload all associated columns making it breach the limit
Hello @iamvivekyubi,
Thank you for your feedback.
Can you please give us more details about when this error happens? Is it when you display a particular record in your DB, or do you experience this error in the table view?
Do you have smart fields defined on the collection?
We get this in table view. The table is clean with no smart fields but has lot of smart actions associated to the same
Could you please share with us the requested URL? We’ll be able to look at the requested fields.
Thank you.
Thanks for your answer,
I would need the requested URL (from the developer console), that leads to a 500, not the URL of the frontend.
The requested URL will contain the list of requested fields. This will help us identify if the problem comes from the frontend configuration (too many fields displayed in the collection) or in the agent (requesting unused fields).
Thanks for your answer.
We can see that this query is made to retrieve one particular entry, probably to display a detail view of one record.
Do you experience the same error with a query that lists every record? If it’s the case, please share the request too.
Can you activalte the logs of SQL queries? We would need the generated SQL query to see what’s going on. Obviously, the generated SQL is containing more than 1664 fields which is huge. We need to know where this comes from.
Thanks
Hey @iamvivekyubi?
Could you try upgrading to the 7.8.2 version of the agent?
We already fix a few optimization issues between the version you are using and the latest of v7.
Let us know if you are still experiencing this issue after this upgrade 
@jeffladiray will try this out today. Can you let me know what optimisations are taken in 7.8.2? I compared two critical files responsible for this issue between 7.6 and 7.8 and i couldnt see any major difference in includes and preloading done for has_one associations. Do correct me, If my understanding is wrong
This one is on me, I mismatched the version, the fix I was mentionning was shipped in 7.6.8, that you should already have.
Currently, our details view does not support projection (Asking the agent for specific columns), thus returns the whole record. As there is no projection, all the associated records (BelongsTo & HasOne) will be fetched by this service.
I can see that the records display embed ~300 fields, and considering that some of those are relation, this will indeed generate a lot of columns fetched from the database.
If you need a short term fix, this is overridable on the agent side, to either reduce and/or interact with the active record request and optimize it the way you like.
In the meantime, I opened a ticket on our end to check if we’re able to reproduce in an isolated context, and to see if this is something we could reduce automatically.
Thanks @jeffladiray can you explain more on Howtos for the short term fix?
We have a documentation regarding Route override here.
You’ll need to override the “Show” method, and return a similar payload with your own strategy.
Let me know if that helps
Will try this out and let you know. Thanks.
1 Like
We tried this approach by overriding perform(instead of show) so that we can control the records fetched(exclude all associations). The issue is temporarily resolved.
Would be great if FA provides this as a feature in a much cleaner way, to ignore associations unless needed via configuration. Please prioritise the same as a bug
