Skip to content

Document error behavior for HTTP & OpenAPI #985

Closed
@matthias-pichler

Description

@matthias-pichler

Discussed in #978

Originally posted by matthias-pichler August 19, 2024
Currently the default output behavior for the call: http task is content which returns the content (i.e. body) of the response. This is very convenient since authors most likely want the response data. However it is very unintuitive when the API returns an error. Since jq will happily return null if non existing properties are accessed subsequent tasks might seem to work or the workflow might fail many steps downstream. Should we update the ergonomics around error handling?

  1. Should call: http raise an error if a not-ok (outside of [200, 399]) status is reported?
  2. Should the default output type be changed to response to report the whole response?
  3. should we allow to specify an expected status (range)?

We should document that call: http and call: openapi raise a communication error for status codes outside of [200, 399]

Metadata

Metadata

Assignees

Labels

change: documentationImprovements or additions to documentation. It won't impact a version change.change: fixSomething isn't working. Impacts in a minor version change.

Type

No type

Projects

Status

Done

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions