We have two views one of them returns empty response {} when there’s no data but the other one throws exception NOT_FOUND, is there a way to address this?
Hi @sameerargade,
can you share your views implementation?
rpc getPrequalChecklistAnswers(ValidDealIdRequest) returns (stream DealPrequalChecklistAnswers) {
option (kalix.method).view.query = {
query: “SELECT * FROM lending_prequalification_checklist WHERE deal_id = :deal_id”
};
option (google.api.http) = {
get: “/deals/getPrequalChecklistAnswers”
};
}
message ValidDealIdRequest {
string deal_id = 1 [(kalix.field).entity_key = true];
}
message DealPrequalChecklistAnswers {
string deal_id = 1;
repeated LendingPrequalificationChecklistItem lending_prequalification_checklist = 2;
}
This returns empty array
and this one returns not_found/
rpc getCreditOriginationPathway(ValidDealIdRequest) returns (LendingPrequalificationOutcome) {
option (kalix.method).view.query = {
query: “SELECT * FROM lending_prequalification_outcome WHERE deal_id = :deal_id”
};
option (google.api.http) = {
get: "/deals/getCreditOriginationPathway"
};
}
message LendingPrequalificationOutcome {
string deal_id = 1;
string lending_prequalification_outcome = 2;
string application_type = 3;
string signpost_message = 4;
}
The difference between the two views, and the reason one responds with a non OK HTTP response code, is that getPrequalChecklistAnswers
is a stream
.
A stream consists of zero to many found entries, so no result is a valid empty stream of results.
getCreditOriginationPathway
is a single entry response, if there is no query result entry, there is nothing to return, and Kalix will return 404 NotFound
(or if called over gRPC, code 5 NOT_FOUND
).
If you want to always return an OK response for the single response, regardless if it found anything or not, I think you could do that by defining a response message and project the result into a nested repeated
field it like shown in the view documentation here. That way the field should be empty if nothing is found, or contain the single found entry if it exists. Another alternative would be to turn the single response query into a stream
response.
Yes, that’s how it’s handled currently , we were expecting kalix views to be consistent over its own datatypes,
That is what I claim it is, a stream is zero to many elements, while returning a single thing is either one thing or it is an exception. You can compare it to a Java method returning a collection, which may be empty or have many elements vs returning an object of some type and if there is no object to return it throws an exception (rather than returning null
which is error prone). Collecting that result into a field in a message is much like using the Java Optional
return type to signal that there may or may not be an actual value returned.