API release 61.3 moves the event count out of the search request. The count_only field left Search_Request, and a dedicated endpoint replaces it. snouty never exposed count_only, so this is a new capability. The spec is vendored in src/openapi.json as of #300.
POST /api/v0/runs/{run_id}/events/search/count takes Search_Count_Request: { "query": string, "validate_only": boolean }. query is an event-set DSL pipeline, the same grammar runs search sends.
- The response is a single JSON object,
Search_Count_Response: { "count": integer }. No limit applies.
- With
validate_only set, the server answers 200 with an empty body for a query that parses, and 400 for one that does not, and computes no count.
- The endpoint documents a
503 with an optional Retry-After header when the events query backend is unavailable.
The runs search command and the event-set DSL are behind the runs-search unstable feature, so the count belongs behind the same gate until that API stabilizes.
API release 61.3 moves the event count out of the search request. The
count_onlyfield leftSearch_Request, and a dedicated endpoint replaces it. snouty never exposedcount_only, so this is a new capability. The spec is vendored insrc/openapi.jsonas of #300.POST /api/v0/runs/{run_id}/events/search/counttakesSearch_Count_Request:{ "query": string, "validate_only": boolean }.queryis an event-set DSL pipeline, the same grammarruns searchsends.Search_Count_Response:{ "count": integer }. Nolimitapplies.validate_onlyset, the server answers200with an empty body for a query that parses, and400for one that does not, and computes no count.503with an optionalRetry-Afterheader when the events query backend is unavailable.The
runs searchcommand and the event-set DSL are behind theruns-searchunstable feature, so the count belongs behind the same gate until that API stabilizes.