AshEvents wrapping prevents `update_default` from working on update actions

[gtolarc]

Code of Conduct

• I agree to follow this project's Code of Conduct

AI Policy

• I agree to follow this project's AI Policy, or I agree that AI was not used while creating this issue.

Versions

Environment

• Elixir version: 1.18.4
• Ash version: 3.5.34
• AshEvents version: 0.4.3
• AshPostgres version: 2.4.19

Operating system

MacOS

Current Behavior

Description

When AshEvents wraps update actions (via only_actions or by not being in ignore_actions), the update_default attribute option stops working. This means fields like updated_at with update_default: &DateTime.utc_now/0 are not automatically updated when records are modified.

Root Cause

The issue occurs because AshEvents uses UpdateActionWrapper which:

1. Implements Ash.Resource.ManualUpdate
2. Directly calls data_layer.update() bypassing Ash's normal update process
3. This skips the application of update_default values

Reference: /deps/ash_events/lib/events/update_action_wrapper.ex

defmodule AshEvents.UpdateActionWrapper do
  use Ash.Resource.ManualUpdate

  def update(changeset, module_opts, ctx) do
    # ... event creation logic ...
    
    data_layer = Ash.Resource.Info.data_layer(changeset.resource)
    data_layer.update(changeset.resource, changeset)  # <- Bypasses update_default
  end
end

Steps to Reproduce

1. Create a resource with AshEvents extension and timestamps:

defmodule MyResource do
  use Ash.Resource,
    extensions: [AshEvents.Events]

  events do
    event_log MyApp.EventLog
    only_actions [:update]  # or don't use ignore_actions
  end

  actions do
    defaults [:create, :read]
    
    update :update do
      accept [:name]
      require_atomic? false
    end
  end

  attributes do
    uuid_primary_key :id
    attribute :name, :string
    timestamps()  # Creates updated_at with update_default: &DateTime.utc_now/0
  end
end

2. Create and update a record:

{:ok, record} = MyResource |> Ash.Changeset.for_create(:create, %{name: "Initial"}) |> Ash.create()
Process.sleep(100)  # Ensure time difference
{:ok, updated} = record |> Ash.Changeset.for_update(:update, %{name: "Updated"}) |> Ash.update()

# Expected: updated.updated_at != record.updated_at
# Actual: updated.updated_at == record.updated_at (NOT UPDATED!)

Impact

This affects:

• All resources using AshEvents with update actions in only_actions
• Timestamp tracking (updated_at fields)
• Any custom fields using update_default
• State machine transitions (when using AshStateMachine with AshEvents)

Workaround

Currently, the only workaround is to exclude affected actions from event logging:

events do
  event_log MyApp.EventLog
  ignore_actions [:update, :state_transition_action, ...]  # Add actions that need update_default
end

Or use a manual change to update the timestamp:

update :update do
  change set_attribute(:updated_at, &DateTime.utc_now/0)
end

Expected Behavior

AshEvents should preserve the normal Ash update behavior, including the application of update_default values, while still logging events.

Environment

• Elixir version: 1.18.4
• Ash version: 3.5.34
• AshEvents version: 0.4.3
• AshPostgres version: 2.4.19

Possible Solutions

1. Apply update_defaults before calling data_layer.update(): The wrapper could manually apply update_default values to the changeset before passing it to the data layer.

2. Use Ash's internal update process: Instead of directly calling data_layer.update(), find a way to use Ash's internal update mechanism that applies defaults.

3. Document the limitation: If this is intentional behavior, it should be clearly documented that update_default doesn't work with event-logged actions.

Additional Context

This issue was discovered while implementing a notification system where state transitions needed to be tracked with accurate timestamps. The updated_at field was not being updated for any state machine transitions or update actions that were included in AshEvents logging.

The issue affects both simple updates (changing a single field) and complex operations (state transitions, generic actions that internally call updates), regardless of implementation complexity.

Reproduction

No response

Expected Behavior

No response

[gtolarc]

@zachdaniel @Torkan This issue is causing significant problems in production systems. The fact that updated_at timestamps are not being updated when AshEvents is enabled is a critical issue that breaks fundamental data tracking functionality.

Impact

• Data Integrity: Without accurate updated_at timestamps, it's impossible to track when records were last modified
• Audit Trail: Timestamps are essential for audit logging and compliance requirements
• Cache Invalidation: Many systems rely on updated_at for cache management
• API Responses: Clients expect accurate modification timestamps

Current State

This issue has been open for 3 weeks without resolution. Meanwhile:

• PR Add support for upsert actions. #63 addresses upsert functionality issues (another critical bug with AshEvents)
• Both issues stem from the same root cause: Action wrappers bypassing Ash's normal processing

Urgent Request

Could we please prioritize fixing both issues together? The pattern is clear:

• UpdateActionWrapper bypasses update_default processing (this issue)
• CreateActionWrapper bypasses upsert processing (addressed in PR Add support for upsert actions. #63)

Both wrappers need to properly delegate to Ash's internal action processing instead of directly calling data layer methods.

Suggested Approach

1. Review and merge PR Add support for upsert actions. #63 for upsert support
2. Apply the same pattern to fix UpdateActionWrapper for update_default support
3. Consider a comprehensive review of all action wrappers to ensure they preserve Ash's built-in functionality

Workaround Impact

Currently, we have to choose between:

• Having event tracking (but broken timestamps and upserts)
• Having working timestamps/upserts (but no event tracking)

This is not a sustainable situation for production applications.

Please consider prioritizing these fixes. Many of us in the community would be happy to help test or review changes. The combination of PR #63 and a fix for this issue would make AshEvents production-ready again.

Thank you for your work on this important extension!

[zachdaniel]

Despite the high level of support that this and other Ash projects offer, please recall that this is a volunteer effort. If you wish to see a fix prioritized, it would be in your best interest to make a PR with a proposed fix.

[zachdaniel]

With that said, it is unlikely that we will be able to go through the existing action logic, so we will just need to make the update logic in this extension aware of update defaults.

[Torkan]

That being said, I am planning to address this issue amongst others, and hopefully have a fix out in the upcoming week 😅

[zachdaniel]

In that case don't make a PR 😆

[zachdaniel]

This issue has been open for 3 weeks without resolution. Meanwhile:

The main thing I want to point out is that you should assume that these kinds of things will never change unless you provide the effort to change them. OSS users are not customers, there should be no expectation on a speedy resolution of issues.

[zachdaniel]

Currently, we have to choose between:

Having event tracking (but broken timestamps and upserts)
Having working timestamps/upserts (but no event tracking)

Didn't you say you had a workaround using set_attribute also?

[zachdaniel]

@Torkan I imagine all we need to do here is consider any keys with update defaults as always changing because I think they'll be set in the changeset given to the manual action.

[gtolarc]

I believe this module is closely related to the core functionality of ash, and the best person to resolve this would be the ash maintainer. In particular, I think that serious issues affecting the basic functionality of a project in OSS should be addressed by the maintainer, which is why I raised this issue. I recognize your efforts and am grateful as a user of this project.

[zachdaniel]

I believe this module is closely related to the core functionality of ash, and the best person to resolve this would be the ash maintainer.

If that is your position then keep in mind that you are opting to relying on volunteers for your business with whatever repercussions come from that, up to and including waiting a long time for a fix. 🙂

IMO, you will have the most success with OSS when you consider yourself part of the stewardship of the tools that you use.

At the end of the day, we don't get to decide what others do with their time.