[Fix] @dd handler for default_dynamic_expr/6 with %Ash.Filter{}#220
[Fix] @dd handler for default_dynamic_expr/6 with %Ash.Filter{}#220pcapel wants to merge 1 commit intoash-project:mainfrom
default_dynamic_expr/6 with %Ash.Filter{}#220Conversation
This addresses the issue where a nested filter expression is not properly cast into a dynamic expression compatible with Ecto.
|
Ok, it does look like there is a |
ash-project/ash_sql#220 Nested filters failed to compile correctly. This can be tested by setting the ASH_SQL_VERSION to `main` and observing the test failure (at least until the fix is merged).
|
The test passed against main because of a setup issue. The authorization parts were necessary to trigger the bug. |
|
Hmm...yeah we should be preventing this at the source. Can you describe how this issue initially arose? |
|
I can sure try! Basically we have a read action which has filters in it referencing calculations. Those calculations are also using some deeply nested expressions (with arguments, but I don't think that matters). At first I thought that was all that was going on, but as I tried to get the test to fail consistently, it became apparent that there was an element of authorization involved. So in ash-project/ash_postgres#710, I have a test case that correctly fails as our app does. To get that to happen against main, I needed to pass through a properly setup actor so the policies were getting hit. So it seems like the true root cause might be the composition of the expressions there? |
|
For both that test and our app, if you point to this PR as the |
|
I've fixed the root issue in |
* chore: add tests for the nested filters issue ash-project/ash_sql#220 Nested filters failed to compile correctly. This can be tested by setting the ASH_SQL_VERSION to `main` and observing the test failure (at least until the fix is merged). * fix: test setup * fix: formatting
I ran across this issue when trying to use the pinned commit for my fix for
join_filters. I think this was potentially introduced with the update to the casting logic. When an%Ash.Filter{}appears nested within another expression, it isn't correctly broken down for compatibility with the SQL layer. This leads to compile time errors.I'm not 100% sure this is the best way to address this, but it seems like it ought to be pretty close? Happy to make any changes as requested.
See ash-project/ash_postgres#710 for the tests.
Contributor checklist
Leave anything that you believe does not apply unchecked.