Skip to content

async

System Crashes on Load if Async Not Configured

Oops. I configured a small downstream project with powercrud without requiring ASYNC_ENABLED (actually without even settings.POWERCRUD_SETTINGS which is an bigger fail gievn it didn't report that was the issue). The system crashed on load because it tries to load django_q and requires settings.Q_CLUSTER even when not required.

We need to put some guards in to m ake the system robust. I got too caught up in my current dev environment with a very sophisticated setup for powercrud and forgot about the basic use cases. Oops.

✅ Async Task Context

This is to provision functionality which addresses this issue:

Downstream Project save() async descendant updates

In a current downstream project that I have, in the save() method of a number of models we have extensive updates (and creates, but that's not relevant to conflict checking) of descendant objects. And I will probably make these run async as part of the save() method. Of course I would want to flag them for conflict detection and management in the same framework.

However if we do this, then if we had a bulk update of a number of objects we would have a problem:

  • send all objects to be updated async. We do not know about the descendant objects from within powercrud so only have parent id's.
  • call save() for object
  • then within save() try to call async task for descendant updates
  • the async sub-tasks all appear to complete immediately and our parent task ends, even though subtasks are continuing (perhaps for quite a while)

So what we want is a kwarg in the save() method - let's say skip_async. And if that's the case then we do not raise the descendant update as a new async task, however what we do is add all those descendant objects to the conflict store.

Django Async Task Conflict Prevention for PowerCRUD

By introducing async processing we introduce potential conflicts. Also want to allow downstream project developers to use the same base mechanism for conflict detection, in case they want to run async processes independent of powercrud (eg save() method that updates child and descendant objects) but want overall conflict detection.

Problems to Solve

  1. Lock conflicts - preventing simultaneous updates to same objects
  2. User state confusion - users making decisions based on stale data while async tasks are running
  3. Race conditions - timing-dependent bugs in concurrent operations
  4. Complex dependencies - bulk operations, single saves with descendant updates, and async tasks can all affect overlapping sets of objects
  5. Downstream flexibility - powercrud needs to work with any downstream project's specific object relationships