When an action fails after authentication, a query or an insert, I try to identify the layer that failed before changing policies or rebuilding the flow.
A simple first check is the Network panel:
• No request was sent: inspect the FlutterFlow action chain, conditions, automatic navigation and auth-state changes.
• The request returns 401 or 403: inspect the active session and RLS policies.
• The request succeeds but the UI crashes: inspect nullable response fields, list access and widget bindings.
• The write succeeds but FlutterFlow keeps loading: check whether the operation returns data that the current user is not allowed to select.
A temporary Snackbar or Set State action between two steps can also show exactly where an action chain stops.
This distinction sounds small, but it prevents a lot of random changes, especially disabling RLS when the request never reached Supabase in the first place.
When asking for help, the most useful evidence is usually:
1. The action sequence.
2. Whether a network request was sent.
3. Its status code.
4. The relevant Supabase log entry.
5. Whether the problem changes between Test Mode and a deployed build.
What failure pattern has wasted the most time in your FlutterFlow projects?