Ecto primary key casting - What am I missing here?

Doing a refactor I recently ran into this error when writing a regression test .

(Ecto.Query.CastError) deps/ecto/lib/ecto/repo/queryable.ex:373: value `"dogs"` in `where` cannot be cast to type :id in query:

I realize that for a long time I’ve been making the false assumption that if I pass a nonsense string as a parameter for the primary to Repo.get(SchemaName, string_input), that the default Ecto primary key casting queued by the query build would return an error/nil result when it couldn’t parse the string to an interger, rathan that raising the CastError.

My question is not how to handle this, I can explicitly cast and pre-validated the input just fine, but rather what pattern people are using for this in a routine situation of accepting a web param for id and doing a lookup. Is there some sort of option I’m missing for Ecto or a reason to do explicit interger casting here that I’m not seeing?

Usually I let the fallback controller catch this kind of errors, as IDs are seldom named by users in services I have built.

What I’m really trying to avoid here is exceptions being throw for invalid query params, and to determine if I’ve misunderstood what sort of explicit typecasting Ecto is expecting for externally sources query params. Is there some sort of automatic casting option I’m missing, is this something not included for a reason I’m missing, or is it just a matter of building a vanilla utility to handle this for every resource.

What you put in your ecto queries is up to you to control. Ecto simply expects data, which can be cast to the type of field in question. As always you should validate user supplied data before passing it to any business logic. Ecto will fail quite nicely, which doesn’t make it that hard a requirement, but if you want to be thorough that’s the way to go.