Bug: GET /events with destination_id returns 500

[leggetter]

Bug: GET /events with destination_id returns 500

Summary

When calling GET /events with the optional query parameter destination_id, the API returns 500 Internal Server Error instead of a successful response or a documented error (e.g. 401, 422).

OpenAPI spec

• Path: GET /events (admin list events)
• Query param: destination_id (optional) – "Filter events by destination ID."
• Documented responses: 200, 401, 422 only. 500 is not documented.

So this is an API bug: the spec declares destination_id as a valid parameter and does not document a 500 response.

Steps to reproduce

1. Create a tenant and a webhook destination.
2. Publish an event that is routed to that destination.
3. Call GET /events?tenant_id=<tenant_id>&destination_id=<destination_id> (with Admin API Key).
4. Observe 500 instead of 200 with a paginated list of events.

Expected behavior

• 200 with EventPaginatedResult (models + pagination) when the request is valid and the tenant/destination exist.
• Or a documented error (e.g. 401 Unauthorized, 422 Validation error) if the request is invalid.

Environment

• Reproduced via spec-sdk-tests (TypeScript SDK) and curl against a running Outpost API.

Possible follow-ups

• Fix the backend so filtering by destination_id returns 200 when applicable.
• If 500 can occur in some cases by design, document it in the OpenAPI spec (e.g. add a 500 response description).

[alexluong]

I'm not 100% sure if we should classify this as a bug, see #676

The reason for the PR is we may want to support it after we persist the matched_destination_ids for events. Not 100% sure tho 👀. Do you think we should prevent this query pattern altogether?

[leggetter]

If the behavior isn't documented in the official docs or the API spec, I'd argue that, from a developer's perspective, it's a bug.

If 500 can occur in some cases by design, document it in the OpenAPI spec (e.g. add a 500 response description).

It still feels strange that we have this behavior, but if it is by design, we should document it as recommended.

[leggetter]

Or remove the unsupported functionality from the OpenAPI spec. That way:

1. Nobody will try to use it
2. SDKs won't generate functions that try to use it and expose it to developers

[alexbouchardd]

Remove it we'll add it back when we do support it

[alexluong]

I take it that you think this is a query pattern we do want to support later when possible? @alexbouchardd

[leggetter]

Will remove in #690

[alexbouchardd]

I take it that you think this is a query pattern we do want to support later when possible? @alexbouchardd

Yes