Further developments from pursuing deeper integration in the Amperity app. The "response info" which pulls observability data such as the HTTP status code, headers, request id, and so on is attached to the returned values as metadata, or to exceptions in the ex-data map. The control flow handler is expected to pull it from these sources to record to the tracing system.
However, there's one spot where this falls through, because in the event of a non-success response, the handle-failure function is called on the exception before it is passed to the control flow, and is allowed to replace it with a value. One use for this is implementing a :not-found option, such as in kv2/read-secret. An extremely common pattern for this is to tolerate missing secrets by passing :not-found nil, then checking for presence of the result. However, nil can't carry metadata! So in this case, the control flow handler would be missing all of the response information.
Instead, just have the client pass the response info directly to the on-success! and on-error! protocol methods, similar to call. It's still attached as metadata and exception data, but now the flow handler is not reliant on those channels.
Further developments from pursuing deeper integration in the Amperity app. The "response info" which pulls observability data such as the HTTP status code, headers, request id, and so on is attached to the returned values as metadata, or to exceptions in the
ex-datamap. The control flow handler is expected to pull it from these sources to record to the tracing system.However, there's one spot where this falls through, because in the event of a non-success response, the
handle-failurefunction is called on the exception before it is passed to the control flow, and is allowed to replace it with a value. One use for this is implementing a:not-foundoption, such as inkv2/read-secret. An extremely common pattern for this is to tolerate missing secrets by passing:not-found nil, then checking for presence of the result. However,nilcan't carry metadata! So in this case, the control flow handler would be missing all of the response information.Instead, just have the client pass the response info directly to the
on-success!andon-error!protocol methods, similar tocall. It's still attached as metadata and exception data, but now the flow handler is not reliant on those channels.