Support async processing on hosting where workers are not available

Created on 10 June 2025, 26 days ago

Problem/Motivation

The sm messenger:consume asynchronous works great on hosting that supports long-running workers, like Platform.sh (https://docs.platform.sh/create-apps/workers.html).

On other hosting providers, we can adopt two different solutions:

* process async messages after the Kernel has returned the response to the user (listening to 'kernel.terminate' event)
* process async messages with cron

Proposed resolution

Implement a new service AsynchronousMessagesProcessor that can be used by an event listener (provided by sm but not registered to the service container by default), or by cron.

Remaining tasks

Review the code

User interface changes

None

API changes

None

Data model changes

None

Feature request
Status

Active

Version

1.0

Component

Code

Created by

🇮🇹Italy lussoluca Italy

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @lussoluca
  • 🇮🇹Italy lussoluca Italy

    This MR also contains code from Implement retry Active because it needs support for async transports

  • Pipeline finished with Failed
    26 days ago
    Total: 195s
    #519103
  • Pipeline finished with Failed
    26 days ago
    Total: 214s
    #519140
  • Pipeline finished with Success
    26 days ago
    Total: 165s
    #519144
  • Pipeline finished with Success
    26 days ago
    Total: 201s
    #519151
  • 🇦🇺Australia dpi Perth, Australia

    We need to postpone this on getting the SQL side in first.

    The code right now is a spaghetti mess.

    I'm not sure about the premise of this issue. To date, I've recommended using the limit=Xseconds command combined with traditional cron if the platform is intolerant of long running commands. Why is that not a viable option for Platform.sh?

    Secondly, if a platform doesnt support async, then perhaps they should just consider using synchronous sending?

    Lateruntime/kernel-termination processing of async messages, or "poor-mans-async" is a bit questionable. I'm wondering if that should just be a different contrib, since its not something we should ever be endorsing.

Production build 0.71.5 2024