shield fails requests for parameter objects that have more properties then definition

[samuba]

calling this telefunction

export async function myTelefunc(args: { foo: string }) {
	// code
}

with an additional property in the object will fail the request with 403

myTelefunc({ foo: "o", bar: "b"})

Not sure if I'm considering this a bug or not. It is definitely unexpected and dangerous behaviour which can cause your production build to fail unexpectedly because as far as typescript is concerned the types match and it will not give you a type error or warning if you write myTelefunc({ foo: "o", bar: "b"})

[brillout]

production build to fail unexpectedly

I'd argue it's a good thing: your code is doing something unexpected and should be fixed. (I actually wonder why TypeScript doesn't complain about this.)

So I'd say: it's not a bug but a feature.

But feel free to let me know if you find situations when it's actually annoying. E.g. if the error message is confusing, then that should be fixed.

Closing in the meantime.

[samuba]

Ah sorry for not being clear enough: It is not the build process that is failing but the (deployed) production build at runtime.
The build process runs just fine, I would agree that if it fails at build time It's kinda a good thing, but failing only at production runtime without prior hints or warning is dangerous.

[brillout]

I agree. PR welcome to fail earlier. It may be tricky to implement though.

[samuba]

As mentioned in #57 this is a massive footgun. Yesterday I had the fourth bug in production because of this behaviour.
The usecase was reading users config from localstorage and then sending it to a telefunc. Some months ago I removed a field from the config and only today found out that apparently some users still have that field in their localstorage, because those requests fail for them.

Can we reopen this issue? It is really not solved.

I think a good solution would be to have a config option that makes shields not fail on objects with obsolete fields.
My server code only operates on known fields anyway, and I bet a lot of others also.

[brillout]

I'm still thinking it would be better to fail earlier instead of being permissive. Because, if you want to be permissive, then you can/should use a more permissive type such as Record<string, any>.

Feel free to disagree and/or create a new feature request for it.