Wow - I was just about to make this change myself; we've had a security near-miss due to the miss error here. Thanks!!

This is a must

@Expurple Thanks for the review!
I see that there are some unrelated cargo fmt and clips failures; Should I fix them in this PR as well?

(re-pushed to fix a test)

Meanwhile, you can add this in your project's Cargo.toml:

[patch.crates-io]
sea-orm = { git = "https://github.com/nodeav/sea-orm", branch = "panic-on-serialization-failure" }

(in case someone's affected and doesn't know about this Cargo feature)

@nodeav oops, something more serious broke this time 😁 As I think about it, let's roll back that Cargo.toml change. It can also cause conflicts when cherry-picking the commit into master later

@nodeav oops, something more serious broke this time 😁 As I think about it, let's roll back that Cargo.toml change. It can also cause conflicts when cherry-picking the commit into master later

Oops, should be resolved now hopefully

sorry, as much as I'd like to fix a bug, this contradicts the effort to reduce panics in SeaORM.
ideally, we should somehow propagate and return this error.
do you have a full example of the scenario (with entity, and db operations)?
there might be something we can do without breaking the API

sorry, as much as I'd like to fix a bug, this contradicts the effort to reduce panics in SeaORM. ideally, we should somehow propagate and return this error. do you have a full example of the scenario (with entity, and db operations)? there might be something we can do without breaking the API

The situation we experienced is an object that fails serde serialization, e.g.

#[derive(Serialize])
#[serde(tag = "type")]
enum Foo {
    Opt1(String)
    // ...
}

When we try to update a column containing this type, the update operation is ignored without errors or warnings. Not only did this eat up considerable engineerings efforts to isolate (it's pretty unusual that ORMs silently ignore operations), but when these objects are sensitive (e.g. authentication/authorization states), they can lead to very dangerous situations.

I completely agree that panics are a last resort but they're always better than silently failing, especially when the error state threatens the integrity of the database.

@nodeav @ytanay if you can add a test case under tests/ that'd be great, and I can see if it's possible to return an Error with some plumbing work

@tyt2y3, I agree with them on this:

panics are a last resort but they're always better than silently failing

A panic is not ideal long-term, but it's already better than what we have now. We can quickly merge the panic, let everyone sleep peacefully, and then proceed with the Error experiments to improve the situation further.

@tyt2y3

@nodeav @ytanay if you can add a test case under tests/ that'd be great, and I can see if it's possible to return an Error with some plumbing work

Moved the test to the tests/ directory.

I'm willing to try going through with the move to TryFrom - though that's arguably more of a breaking change than panicking since it can cause compilation failures in users that rely on the From impl (or we can panic in the From impl)

Anyway, up to you obviously

I see. thanks. can you revert the sea-orm-codegen diff? I will merge this afterwards

I see. thanks. can you revert the sea-orm-codegen diff? I will merge this afterwards

@tyt2y3 Done!

🎉 Released In 1.1.14 🎉

Thank you everyone for the contribution!
This feature is now available in the latest release. Now is a good time to upgrade!
Your participation is what makes us unique; your adoption is what drives us forward.
You can support SeaQL 🌊 by starring our repos, sharing our libraries and becoming a sponsor ⭐.