[Feature request]: Event rejection for unmatched filters about convoy

[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

[linear]

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