mage-os / mageos-async-events Goto Github PK

When mage-os/terraform#44 is finished, it should be possible to configure the default branch via Terraform. However, I wonder why we shouldn't just use the main branch for the latest 2.4-compatible version of this extension. I suggest simply renaming / moving the branch 3.x to main. Is there any reason against this, @gowrizrh? Thanks!

If we want to include this module via composer, a release would be very helpful. I'd suggest creating a 3.0 and a 2.0 release.

@gowrizrh @aligent-lturner Thanks for your great work on this module!

Currently \MageOS\AsyncEvents\Model\Indexer\LuceneSearch returns a list of all records if a match wasn't found in Elasticsearch. This is counter intuitive and instead should behave such that

1. When a lucene query hit is received, return the relevant records from Magento.
2. When there are no hits, force set an id filter like "0" so that no records are returned. This let's the UiComponent display "We couldn't find any records."
3. If there is no query provided, just return normally without any filter.

Async Event Subscriptions are globally scoped. It might make sense to scope them down to the store level.

Currently, all failures are retried if they are not successful. There are situations where it is unnecessary to retry when we know it will fail.

For example, In a HTTP context, if the external system returns a 4xx status code denoting client error we should skip retrying.

https://github.com/cloudevents/spec/blob/main/cloudevents/primer.md

An event includes context and data about an occurrence. Each occurrence is uniquely identified by the data of the event.

Events represent facts and therefore do not include a destination, whereas messages convey intent, transporting data from a source to a given destination.

Eventing

Events are commonly used in server-side code to connect disparate systems where the change of state in one system causes code to execute in another. For example, a source may generate an event when it receives an external signal (e.g. HTTP or RPC) or observes a changing value (e.g. an IoT sensor or period of inactivity).

To illustrate how a system uses CloudEvents, the simplified diagram below shows how an event from a source triggers an action.

The source generates a message where the event is encapsulated in a protocol. The event arrives to a destination, triggering an action which is provided with the event data.

A source is a specific instance of a source-type which allows for staging and test instances. Open source software of a specific source-type may be deployed by multiple companies or providers.

Events can be delivered through various industry standard protocols (e.g. HTTP, AMQP, MQTT, SMTP), open-source protocols (e.g. Kafka, NATS), or platform/vendor specific protocols.

• Initial setup
• GitHub Actions

Failing events are retried with exponential back-off. This eases out and handles back pressure accordingly.

However, should the recipient choose to explicitly tell to retry after X seconds, we should be able to respect that no matter the underlying protocol or client.

HTTP

the Retry-After is a standard header in https://tools.ietf.org/html/rfc7231#section-7.1.3.

The value of this field can be either an HTTP-date or a number of seconds to delay after the response is received.

The number of seconds to delay is a great way to introduce client specified back-off since we're already calculating back-off in seconds.

AWS SDK

AWS defines several exceptions for rate limiting RequestLimitExceeded, ThrottlingException, BandwidthLimitExceeded and a few others https://docs.aws.amazon.com/sdk-for-php/v3/developer-guide/faq.html

It already handles it internally within the SDK but should the exception bubble up (because of exceeding max attempts) or any other reason we should be able to leverage that.

The readme in the main branch contains next to no information.
It would be helpful to tell folks they have to visit one of the 2.x or 3.x branches to see the documentation in the readme.