Fix view groups update after field metadata update

[lucasbordeau]

This PR fixes a difficult to reproduce bug, where a race condition appears if we go back to a table with view groups before the update field metadata logic finishes its work.

In order to reproduce this bug on localhost, you'll have to simulate a slow network in your browser.

The problem was that the view groups are initialized only once by useLoadRecordIndexStates, in an effect component : RecordIndexLoadBaseOnContextStoreEffect. And that this component as an internal state loadedViewId, which prevents subsequent updates of view groups by useLoadRecordIndexStates, because it considers that loading already happened, even if it's actually stale data.

So instead of creating other states to burden the effect component with complex state management, the solution was to add the only needed update in a synchronous way directly in updateOneFieldMetadataItem logic. This way we are sure that our boards and tables with view groups get updated eventually, for each field metadata update, even if the requests take time.

Fixes #10947
Fixes #10944

[greptile-apps]

PR Summary

This PR fixes a race condition where view groups could become stale after field metadata updates by implementing synchronous updates in the updateOneFieldMetadataItem function.

• Added direct view group updates in useUpdateOneFieldMetadataItem.ts to ensure synchronous updates after field metadata changes
• Modified useSetRecordGroups to accept objectMetadataItemId directly instead of relying on context store
• Added objectMetadataItem parameter to setRecordGroupsFromViewGroups calls to maintain metadata context during updates
• Removed dependency on effect component's internal state management to prevent stale data issues
• Added proper view record fetching after metadata updates to ensure groups stay in sync

_{5 file(s) reviewed, no comment(s)
Edit PR Review Bot Settings | Greptile}

[ijreilly]

this fixes #10947 right ? I just tested and it seems to !

[ijreilly]

This PR fixes a difficult to reproduce bug, where a race condition appears if we go back to a table with view groups before the update field metadata logic finishes its work.

In order to reproduce this bug on localhost, you'll have to simulate a slow network in your browser.

The problem was that the view groups are initialized only once by useLoadRecordIndexStates, in an effect component : RecordIndexLoadBaseOnContextStoreEffect. And that this component as an internal state loadedViewId, which prevents subsequent updates of view groups by useLoadRecordIndexStates, because it considers that loading already happened, even if it's actually stale data.

So instead of creating other states to burden the effect component with complex state management, the solution was to add the only needed update in a synchronous way directly in updateOneFieldMetadataItem logic. This way we are sure that our boards and tables with view groups get updated eventually, for each field metadata update, even if the requests take time.

@charlesBochet did we not already witnessed issues with the slow update of fieldMetadata ? it rings a bell !

[lucasbordeau]

Indeed it's the same problem, I updated the description.

[charlesBochet]

Agree with all of it. On the back end we call that "related records" updates when we update the object metadata