[Feature request]: Event rejection for unmatched filters

[codeasashu]

Is your feature request related to a problem? Please describe.

When a subscription doesn't match the event due to filters, ingest response still shows the event as accepted. This is frustrating. The panel doesn't show any event being accepted (which is correct behaviour), and the ingest API also doesn't return any error (which is frustrating behaviour)

Describe the solution you'd like

The ingest API should return an ERROR whenever event is discarded due to filter matching algorithm. I am guessing the filters are not matched straighaway, and the API may not have a way to know if it will match. One way to solve this is to return an identifier (similar to task-id in celery) and use it to know the event status. The workers can also update this identifier with status along the way.

Describe alternatives you've considered

Don't know if there is any alternative to this

Additional context

In celery, it is quite easy to track down a task. The "ingest" api in celery (which invokes the task) usually returns a task-id. The task id can then be used to further check the status of task. This is quite handy.

[linear]

CON-298 [Feature request]: Event rejection for unmatched filters

[jirevwe]

Hey @codeasashu

I am guessing the filters are not matched straightaway

Yes, you are right; we immediately enqueue the event so we can't return a status.

One way to solve this is to return an identifier and use it to know the event status

We can do this. I'll look into it.

If you can, you can submit a PR for this; I would appreciate it!

[codeasashu]

@jirevwe I also see that a ingest event may have multiple deliveries. If the first queued delivery isn't success, it will be retired based on the setting. Hence, for an ingested event, we will have an array of deliveries, sorted by timestamps. If there are no forced retries, the latest delivery may have a success status.

In case of forced retries, there may be multiple "success" deliveries". In that case, the user may want to know if it was "forced", hence we can label them.

In conclusion, we can have an API which:

• list all the event deliveries
• able to filter delivery by status (succeeded, failed)
• filter by delivery sources ("forced" is kind of a source of delivery, ingest api is another)

What do you think?
I don't know golang much but I will give this a shot