Did you check the docs?
Is your feature request related to a problem? Please describe.
The /v1/checks endpoint returns no observability into which rails ran, their execution order, or timing.
Describe the solution you'd like
Support an options.log field in the /v1/checks request (consistent with how /v1/chat/completions handles it) that enables opt-in log data in the response, e.g. activated_rails list. The response shape could add an optional log field that is only present when requested.
Describe alternatives you've considered
I considered relying solely on:
- external observability only (tracing/metrics); this is useful but doesn't help with request-scoped debugging
Additional context
This issue is closely related to the RailsResult SDK contract question (issue for extending RailsResult with richer metadata (#2062)). If RailsResult is extended to include activated rails and per-rail status at the SDK level, surfacing log data here becomes straightforward; just expose the new fields in the response. If RailsResult stays thin, the endpoint would need to reach past check_async() into GenerationResponse/GenerationLog directly, which couples the server to internal structures. The approach taken on the SDK contract will likely inform the design here.
Did you check the docs?
Is your feature request related to a problem? Please describe.
The
/v1/checksendpoint returns no observability into which rails ran, their execution order, or timing.Describe the solution you'd like
Support an
options.logfield in the/v1/checksrequest (consistent with how/v1/chat/completionshandles it) that enables opt-in log data in the response, e.g.activated_railslist. The response shape could add an optionallogfield that is only present when requested.Describe alternatives you've considered
I considered relying solely on:
Additional context
This issue is closely related to the
RailsResultSDK contract question (issue for extendingRailsResultwith richer metadata (#2062)). IfRailsResultis extended to include activated rails and per-rail status at the SDK level, surfacing log data here becomes straightforward; just expose the new fields in the response. IfRailsResultstays thin, the endpoint would need to reach pastcheck_async()intoGenerationResponse/GenerationLogdirectly, which couples the server to internal structures. The approach taken on the SDK contract will likely inform the design here.