werner291

How about we pre-process the search index like this? `SELECT translate('https://www.youtube.com/watch?v=dQw4w9WgXcQ', './:?=', ' ');` This results in a breakdown like this: `https www youtube com watch vdQw4w9WgXcQ` which should be...

Removing special characters would happen around here then, probably: https://github.com/matrix-org/synapse/blob/master/synapse/storage/search.py#L326 Note that we're essentially already doing that here: https://github.com/matrix-org/synapse/blob/master/synapse/storage/search.py#L695

How odd... When entering the URI in Riot search it doesn't seem to always work, yet it seems mostly reliable when running the tests. Yes, I'm running with `SYNAPSE_POSTGRES=1`

:man_facepalming: I forgot how federation worked, was running the search against a non-upgraded server. On a more positive note, URI search seems to work very well!

Note that the improved search will only work on messages newly inserted into the search index. (Old messages will behave the same as before.) It will also only work on...

Also, the error message itself: ``` thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /home/werner/.cargo/registry/src/github.com-1ecc6299db9ec823/rapier3d-0.14.0/src/dynamics/solver/generic_velocity_ground_constraint.rs:63:14 stack backtrace: 0: rust_begin_unwind at /rustc/fa6ee9375242ae784dab1837dfc0b92f43e787ce/library/std/src/panicking.rs:584:5 1: core::panicking::panic_fmt at /rustc/fa6ee9375242ae784dab1837dfc0b92f43e787ce/library/core/src/panicking.rs:142:14 2: core::panicking::panic at...

I can also confirm that using an `ImpulseJoint` simply works (in the example above).

Bit of debugging later, updated to `bevy_rapier` 0.17, issue still there. Here's a bit in `GenericVelocityGroundConstraint::generate`: ``` let (mb2, link_id2) = handle2 .and_then(|h| multibodies.rigid_body_link(h)) .map(|m| (&multibodies[m.multibody], m.id)) .unwrap(); let mj_lambda2...

It being RigidBody::Fixed definitely plays into it, there's no error when the big box is Dynamic (I visually confirmed there's a collision)

The ground being fixed puts the interaction into `SolverConstraints::generic_ground_interactions`, that presumably plays a role in it, otherwise that code path is unreachable