Bug report for trillium-api: wanting a State and not getting it should *usually* be a 500, not a 404

[joshtriplett]

Multiple times, I've run into the bug that the state map didn't have the type I was expecting in it. trillium-api treats an unavailable State<T> parameter as a failure to use that route, and thus a 404. However, based on experience with trillium-api, it seems like a missing State<T> is often an internal server error.

When a non-optional State<T> parameter fails to be available, I think it would make sense to:

1. Produce a 500 Internal Server Error.
2. Produce an error message to the log.

[jbr]

I don't think this is a bug, in that it behaves as I expect and intend. I tend to treat "state not populated" to mean something like "we couldn't find the record," which is a 404. However, your expectation of "state not populated" meaning "our application is broken because the type in state is a critical component that should always be populated" also seems valid and reasonable. Can you describe the situation in which something should have been populated into State but was not? It seems like the place that populates the State is where I'd expect to halt and log and populate an error of some sort, but I can't be sure of that without more context

[joshtriplett]

The scenario I've most often observed: calling a function that returns an Option<T> or Result<T, E> and accidentally putting that into the state map without first extracting the T from it.