Refactor findStripeSubscriptionIdForTeam to return a 404 error instead of `undefined` when something cannot be found

[jankeromnes]

Is your feature request related to a problem? Please describe

Refactor all findStripeSubscriptionIdForTeam to return a 404 error instead of undefined when something cannot be found to be differentiate precisely between various cases.

Describe the behaviour you'd like

E.g.

async findSomething(query): Promise<Something | undefined> {
    if (!something) {
        return undefined;
    }
    return something;
}

would become

async findSomething(query): Promise<Something> {
    if (!something) {
        throw new ResponseError(ErrorCodes.NOT_FOUND, "Could not find something");
    }
    return something;
}

This would of course also need to be handled by all clients, for example the dashboard (where a undefined check should become a 404 error catcher).

Describe alternatives you've considered

• Staying with undefined (status quo)

Additional context

[geropl]

Sorry, I don't understand the motivation for this change. Why? The current way clearly fits the RPC model we're following.

@easyCZ Do you have some context? 🤔

[easyCZ]

The reasoning for this change is that on the server side, we clearly know that a record was not present in the database. However, when we return undefined, we no longer can distinguish between bad data quality, or entry missing or something else gone wrong.

The secondary benefit is that first-class errors (404) allow us to monitor the service better and more accurately say what is a user error, what is not and if the behaviour is "expected" or "unexpected".

[geropl]

I agree with both points in the specific case of the method cited. 👍

But I want to emphasize two points:

1. The current API is something we do not want to invest in. Thus the scope layed out in the title/description ("refactor all server methods") is not sth we want to engage with, ever.
2. While I agree that having explicit errors is nice (for instance for distinguishing between "not there" and "error while searching for it"), it fits very well with the TypeScript style RPC scheme we have going here. 🙃

To conclude: I will re-scope this issues to this particular method because there is a concrete need and benefit.

[geropl]

Closing as not relevant atm.