AE
Ash Elixir•2y ago
moxley

Notifications warning in migration

I'm getting a warning [warning] Missed 1 notifications in action GF.WebComponents.WebSite.update in the logs when running a new migration that calls an :update action on a resource. I know very little about Ash notifications and how they work. I don't want to disable them globally, because they might be useful in the future. How can I prevent this warning from appearing when the migration runs?
12:39:17.050 [warning] Missed 1 notifications in action GF.WebComponents.WebSite.update.

This happens when the resources are in a transaction, and you did not pass
`return_notifications?: true`. If you are in a changeset hook, you can
return the notifications. If not, you can send the notifications using
`Ash.Notifier.notify/1` once your resources are out of a transaction.

(elixir 1.14.3) lib/process.ex:773: Process.info/2
(ash 2.13.2) lib/ash/actions/helpers.ex:239: Ash.Actions.Helpers.warn_missed!/3
(ash 2.13.2) lib/ash/actions/update.ex:176: Ash.Actions.Update.add_notifications/6
(ash 2.13.2) lib/ash/actions/update.ex:38: Ash.Actions.Update.run/4
(ash 2.13.2) lib/ash/api/api.ex:2036: Ash.Api.update!/3
(elixir 1.14.3) lib/enum.ex:975: Enum."-each/2-lists^foreach/1-0-"/2
(ecto_sql 3.10.1) lib/ecto/migration/runner.ex:289: Ecto.Migration.Runner.perform_operation/3
(stdlib 4.3) timer.erl:235: :timer.tc/1


While you should likely leave this setting on, you can ignore these or turn them into errors.

To ignore these in all cases:

config :ash, :missed_notifications, :ignore

To turn this into raised errors:

config :ash, :missed_notifications, :raise
12:39:17.050 [warning] Missed 1 notifications in action GF.WebComponents.WebSite.update.

This happens when the resources are in a transaction, and you did not pass
`return_notifications?: true`. If you are in a changeset hook, you can
return the notifications. If not, you can send the notifications using
`Ash.Notifier.notify/1` once your resources are out of a transaction.

(elixir 1.14.3) lib/process.ex:773: Process.info/2
(ash 2.13.2) lib/ash/actions/helpers.ex:239: Ash.Actions.Helpers.warn_missed!/3
(ash 2.13.2) lib/ash/actions/update.ex:176: Ash.Actions.Update.add_notifications/6
(ash 2.13.2) lib/ash/actions/update.ex:38: Ash.Actions.Update.run/4
(ash 2.13.2) lib/ash/api/api.ex:2036: Ash.Api.update!/3
(elixir 1.14.3) lib/enum.ex:975: Enum."-each/2-lists^foreach/1-0-"/2
(ecto_sql 3.10.1) lib/ecto/migration/runner.ex:289: Ecto.Migration.Runner.perform_operation/3
(stdlib 4.3) timer.erl:235: :timer.tc/1


While you should likely leave this setting on, you can ignore these or turn them into errors.

To ignore these in all cases:

config :ash, :missed_notifications, :ignore

To turn this into raised errors:

config :ash, :missed_notifications, :raise
10 Replies
ZachDaniel
ZachDaniel•2y ago
Are you using Ash actions in your ecto migration code? In general, that can cause problems further down the road as you change your resources. I'd typically suggest using raw ecto queries against tables to do that kind of thing.
moxley
moxleyOP•2y ago
I'm calling an Ash action from my ecto migration.
ZachDaniel
ZachDaniel•2y ago
Regardless, you can silence notifications for specific invocations w/ return_notifications?: true and handling them yourself IIRC
moxley
moxleyOP•2y ago
Most of the logic in the migration is adding records, using Ash resources, and Ash changesets. I would have to redefine several Ash resources into Ecto resources to avoid using Ash
ZachDaniel
ZachDaniel•2y ago
that will affect the return shape, i.e {:ok, result, _} = Api.create(..., return_notifications?: true)
moxley
moxleyOP•2y ago
Okay, got it! I was adding return_notifications?: true to the Changeset.for_update() function. Adding it to API.update() makes sense.
ZachDaniel
ZachDaniel•2y ago
All Ash resources are ecto schemas FWIW. And what I generally do is avoid usage of any app level thing for data migrations. i.e
execute("""
INSERT INTO ...
"""
)
execute("""
INSERT INTO ...
"""
)
But if its just a one time migration you need to happen in prod, that you're going to remove later then it really doesn't matter. or at least, that you can remove later
moxley
moxleyOP•2y ago
Doing raw INSERTs would be very difficult, because the record has multiple levels of nested, embedded values. The return_notifications?: true option seems like the best route for this. Or, not doing it in a migration is an option too.
ZachDaniel
ZachDaniel•2y ago
Its all tradeoffs, so I feel you 🙂 mostly just wanted to let you know that it could present an issue in the future.
moxley
moxleyOP•2y ago
Sounds good. Thanks @Zach Daniel !

Did you find this page helpful?