Supabase results not properly type cast in weweb

I have a fairly complex query in a supabase DB function.

The function works fine when I test it within supabase query editor.

When I invoke the function from weweb, I get null results for a specific field.
Now, This field can either be null or a text value (I forced a type cast on it in supabase).
I think weweb is not handling it properly because the value is sometimes null.

Anyone ever got a similar problem ?
As mentioned, everything is fine prior to the webweb handling of the results.

SQL Results
Screenshot 2024-06-10 at 5.57.25 PM

Weweb results (response = null, should be “Non”)
Screenshot 2024-06-10 at 5.58.46 PM

I think sharing the query might help. There might be some issues with how the PostgREST (which is the library that creates the REST layer on top of Supabase) handles your function’s output.


It’s a fairly big query. response is the culprit, everything else works great.

CREATE OR REPLACE FUNCTION get_exp_questionnaire_from_autoeval(i_entreprise_id UUID)
RETURNS TABLE(
thematique_name TEXT,
enjeu_name TEXT,
enjeu_description TEXT,
enjeu_image TEXT,
criteria_name TEXT,
criteria_description TEXT,
criterion_type TEXT,
criteria_id TEXT,
criterion_id TEXT,
question_id UUID,
question TEXT,
response TEXT
) AS $$
BEGIN
RETURN QUERY
WITH full_questionnaire AS (
SELECT
t.name AS thematique_name,
e.name AS enjeu_name,
e.description AS enjeu_description,
e.image AS enjeu_image,
c.name AS criteria_name,
c.description AS criteria_description,
cr.type::TEXT AS criterion_type,
c.id::TEXT AS criteria_id,
cr.id::TEXT AS criterion_id,
q.id AS question_id,
cr.question AS question
FROM
“Entreprise” ent
JOIN “Sector_Questionnaires” s ON ent.sector_id = s.sector_id
JOIN “Questionnaires” qn ON s.questionnaire_id = qn.id
JOIN “Questionnaire_context” qct ON qn.id = qct.questionnaire_id
JOIN “Question” q ON qn.id = q.questionnaire_id
JOIN “Criteria” c ON q.criteria_id = c.id
JOIN “Enjeu” e ON c.enjeu_id = e.id
JOIN “Thematique” t ON e.thematique_id = t.id
JOIN “Criterion_context” cct ON qct.id = cct.questionnaire_context
JOIN “Criterion” cr ON cct.criterion_id = cr.id
WHERE
ent.id = i_entreprise_id
ORDER BY
t.name, e.name, c.name, cr.order_type
),
auto_eval_responses AS (
SELECT
c.id::TEXT AS criteria_id,
cr.id::TEXT AS criterion_id,
r.display_text::TEXT AS response
FROM
“Evaluations” eval
JOIN “Evaluation_Response” resp ON resp.eval_id = eval.id
JOIN “Criteria” c ON resp.criteria_id = c.id
JOIN “Criterion” cr ON resp.criterion_id = cr.id
JOIN “Response” r ON r.id = resp.response_id
WHERE
eval.entreprise_id = i_entreprise_id
)
SELECT
fq.thematique_name,
fq.enjeu_name,
fq.enjeu_description,
fq.enjeu_image,
fq.criteria_name,
fq.criteria_description,
fq.criterion_type,
fq.criteria_id,
fq.criterion_id,
fq.question_id,
fq.question,
aer.response::TEXT
FROM
full_questionnaire fq
LEFT JOIN
auto_eval_responses aer
ON
fq.criteria_id = aer.criteria_id AND fq.criterion_id = aer.criterion_id
ORDER BY
fq.thematique_name, fq.enjeu_name, fq.criteria_name, fq.criterion_type;
END;
$$ LANGUAGE plpgsql;

The query indeed seems fine. What I probably would do is try to curl it, or try to somehow call the endpoint via REST to assess that the issue actually is WeWeb. You can call the functions via the Supabase’s REST API, you can find how to do this in your API Docs.

You might also try to COALESCE the missing field and see if the issue is coming from the DB - you’d get your coalesced fallback, or if it just straight gives you null. I’d probably do this first.

I did try the coalesce. Changed null to “”, but result was basically the same.

I did this :

  • Created a DB Function that creates a dynamic view based on specific client_id
  • Create a dynamic collection in weweb that connects to that dynamic view

Result is now fine and my fields all have expected values.
Seems to point to a weweb issue…

I’d still probably do some more due diligence and give this a shot, also because WeWeb takes a little more to answer tickets, than it takes you to test this out:

You can also use postman for this, and you can get your auth token for the Authorization header from WeWeb, so this should be super quick.

After that, if you conclude that it’s indeed a bug, you can open a ticket at https://support.weweb.io/
I personally never had this kind of issue with WeWeb, but it’s definitely not impossible.

Edit: One thing that actually comes to my mind is that views are SECURITY DEFINER by default. Maybe RLS might be playing a role? Sounds impossible, but might as well be so. You’d probably find out by curling the function with your currrent user’s token.

Edit 2: Based on your query the response seems to be in a standalone table, so maybe it is the RLS after all? By the way - you don’t even need to curl it, you can just simply impersonate that user you’re invoking the function as in WeWeb from the Supabase SQL Dashboard. This should rule out the RLS being an issue.

1 Like

That is great info. Thanks for the advice.

I tried impersonating different roles and always get good results.
Most of my RLS aren’t defined yet as I’m still in dev mode. I usually come back to RLS once a feature is done.

I will create a ticket because this is a show stopper for me. To my knowledge, collections can’t be created dynamically to fit my dynamic view so I can’t really use this except for testing.

I FOUND THE BUG ! It’s me … lol :dotted_line_face:

There was a confusion in the sent parameter to the DB function causing the wrong id to be sent.
I was getting null results because the results for this id are null.
It was hardcoded in my SQL test so I never noticed it.

Sorry for taking some of your time, thank you for your inputs. I still got to learn some interesting technical details along the way.

Thanks again.