fix: handle queries on non-existing table gracefully

[taimoorzaeem]

Add new TableNotFound error and add json error
message for this error. Closes #3697.

(Couldn't think of a better changelog/commit message. Feel free to suggest a new/better message).

[steve-chavez]

Seeing the change in the tests output, I think this should also be listed in ### Changed.

This also means that we should release it on the upcoming major.

[wolfgangwalther]

Does that mean you would not consider backpatching this?

Personally, I don't think this needs to be explicitly mentioned. It's an error condition that nobody relies on. This only comes up when they do something wrong - and they get a better error now. So this is hardly breaking any existing workflows, right?

(maybe I missed the relevant test output change, though - I assume it's about the 400 -> 404, from no foreign key relationship -> no table)

[steve-chavez]

Does that mean you would not consider backpatching this?

Yeah, I was thinking no backpatch. Just to be extra careful.

So this is hardly breaking any existing workflows, right?

I know some users that rely on table requests with no resource embedding being fast (in presence of slow relationships loads), if that has changed (test mentioned on #3869 (comment)) then it would certainly break existing workflows.

[steve-chavez]

Hm, the change in these lines I don't understand. Why does len(output) change from 7 to 5?

[steve-chavez]

Hm, so the empty body {} on an insert error (#3697) was tested. The behavior is a bit weird, it must have escaped review before.

[taimoorzaeem]

A quick git blame reveals that it was introduced in #2542.

[steve-chavez]

Now that we rely on the schema cache for simple table filters, we need to make sure these requests are fast when a schema cache load for relationships is slow (#3046).

There's a test that validates the above behavior (a request with resource embedding is blocked until the schema cache finishes loading):

postgrest/test/io/test_big_schema.py

Lines 10 to 34 in 52591c0

	def test_requests_wait_for_schema_cache_reload(defaultenv):
	"requests that use the schema cache (e.g. resource embedding) wait for the schema cache to reload"
	env = {
	**defaultenv,
	"PGRST_DB_SCHEMAS": "apflora",
	"PGRST_DB_POOL": "2",
	"PGRST_DB_ANON_ROLE": "postgrest_test_anonymous",
	"PGRST_SERVER_TIMING_ENABLED": "true",
	}
	with run(env=env, wait_max_seconds=30) as postgrest:
	# reload the schema cache
	response = postgrest.session.get("/rpc/notify_pgrst")
	assert response.status_code == 204
	postgrest.wait_until_scache_starts_loading()
	response = postgrest.session.get("/tpopmassn?select=*,tpop(*)")
	assert response.status_code == 200
	plan_dur = parse_server_timings_header(response.headers["Server-Timing"])[
	"plan"
	]
	assert plan_dur > 10000.0

We need an additional test that asserts that a table request (with no resource embedding) finishes in a short plan_dur after reloading the schema cache (calling /rpc/notify_pgrst in the test).

[wolfgangwalther]

Do we generally leak the exposed schema name in the output? I'm not a fan, I think this should better be:

Suggested change

	"message":"Could not find relation 'test.foozle' in the schema cache"
	"message":"Could not find relation 'foozle' in the schema cache"

But this might be the wrong PR to raise that, if we do it elsewhere as well.

[taimoorzaeem]

Couldn't find any tests where we do it for tables, but we do it for functions.

postgrest/test/spec/Feature/Query/RpcSpec.hs

Line 1145 in e2dd435

"message": "Could not find the function test.unnamed_int_param in the schema cache",

[wolfgangwalther]

Does that mean you would not consider backpatching this?

Personally, I don't think this needs to be explicitly mentioned. It's an error condition that nobody relies on. This only comes up when they do something wrong - and they get a better error now. So this is hardly breaking any existing workflows, right?

(maybe I missed the relevant test output change, though - I assume it's about the 400 -> 404, from no foreign key relationship -> no table)