The lifecycle of the after* callbacks

#1

I’m wondering when in the lifecycle the ‘afterCreate()’ and afterUpdate() callbacks get executed. For example, lets say i do User.create() , and there’s an afterCreate() defined on the type User.

Will the afterCreate() run async (e.g. create() will not block on afterCreate()) or will afterCreate() run synchronously and block create() from returning?

Can i rely on afterCreate() having been run by the time create() returns?

0 Likes

#2

According to the documentation:

  /**
   * Callback that is called from UpsertTask after objs are created.  The implementer can perform additional logic.
   *
   * @param objs
   *           List of objs that were created.  The objs will already have been created.  By default, only the id
   *           is present in the objs. If more fields are desired a dependency annotation can  be specified (e.g.
   *           `@dependency(include = "field1, field2...")`. Then the objs will have at least those requested fields.
   * @return List of any errors that were encountered.
   */
  afterCreate: optional function(objs: !?[T]): [ObjError]

it says that it is “called from” UpsertTask

as opposed to created which says:

  /**
   * Callback that is called asynchronously in response to objs getting created from {@link create}, {@link upsert},
   * {@link merge} or their batch equivalents.
   *
   * The implementation must be idempotent and also resilient to abnormal or race conditions such as record already
   * being removed or updated.
   *
   * @param txn
   *        Contains details about which objs were created.  This is basically the ids of those objects.  The
   *        implementation will most likely need to fetch the actual instances to do whatever they need.
   */
  @action(group='data-admin')
  created: optional function(txn: !Transaction)

So, the after… callbacks are called from UpsertTask which I thought implied that it was synchronous. If you think clarification would be helpful, file a ticket to clarify it.

1 Like