Fix infinite loop when the typescript client requests a non-existing table

[KyleAMathews]

The server returns a 400 and this line then restarts the fetching

electric/packages/typescript-client/src/client.ts

Line 235 in 371dc56

if (e.status == 400) {

It seems 404 is the proper response code for the server and would fix this issue.

[thruflo]

Are there any other cases where a 400 could be returned. Do we also want to fix infinite loop for 400 generally?

[KyleAMathews]

I'm not sure why we special-case the 400 there — 409 is the code we use to tell the client to refetch. In general 4xx codes are a user error so the client should just throw ann error and quit.

But yeah, to your point, we need to do two things — return 404 from the server for non-existing tables and don't special case the 400 status code.

[balegas]

We used a 400 initially on the server to not specialize the reasons. I guess things have evolved.

[balegas]

One related problem is that the constructor makes the first fetch call, so non-actionable errors can't be caught. We should change the client to separate resource creation (i.e. constructor) from connection initialisation (start) to make it easier to catch non-actionable errors.

[msfstef]

We should change the client to separate resource creation (i.e. constructor) from connection initialisation (start) to make it easier to catch non-actionable errors.

I agree, I think we should open a new issue about this in particular.

I've opened #1880 that should fix this immediate issue of infinite loops.

As an aside, I don't think we should be returning 404 errors since as far as we're concerned any request that defines a shape that is not valid (inexistent or invalid root table, inexistent or invalid column names, mismatched shape id and definition) are badly formed requests, and thus 400s.

If we want to split out errors (e.g. missing table from PG is 404, invalid table name is 400), it would be perhaps more explicit and informative but the handling from our side would be exactly the same, so it would just be a matter of improving API semantics.