💭 Enhancing 🧠 Logic query response on errors

[ccamel]

Context

The logic module, a component of the OKP4 blockchain, enables the compilation of Prolog programs and the submission of queries on-chain. Defined by a protobuf contract, this module mandates a specific formalism for response delivery, enabling access to a series of substitutions that fulfill the given query.

In the current implementation (v6.0.0) the responses given in the event of a predicate evaluation error are not quite correct. For instance:

% program
foo(a1).
foo(a2).
foo(a3) :- throw(error(resource_error(foo))).
foo(a4).

% query
foo(X).

Gives:

error: error(resource_error(foo))
results:
- substitutions:
  - expression: a1
    variable: X
- substitutions:
  - expression: a2
    variable: X
success: true
variables:
- X

This outcome inaccurately suggests that the process completed successfully, as indicated by the success: true status, despite the presence of an error. The issue lies in the system providing solutions for the first two matches prior to encountering the error, yet still returning a status of success. This behavior is misleading since an error did occur.

The objective of this discussion is to deliberate on potential options and assimilate community feedback to augment the correct response formats of the logic module in case of error.

Proposition

General principle

We adhere to the principle that the logic module should return partial results up to the point an error occurs. This method enables the use of solutions found before the onset of an error, which can be invaluable in scenarios where having some data is preferable to none from the client perspective.

Proposed Format

There are 3 possible outcomes for each query:

• A solution is found without any variable substitutions.
• A solution is found that includes variable substitutions.
• An error occurs during the evaluation process.

Solution found with no substitution

We recommend eliminating the success indicator from the response and instead signify a successful query without substitutions by presenting an empty substitutions array. The absence of errors implicitly confirms success.

results:
  - variables: []
  - substitutions: []

Solution found with substitutions

In scenarios where substitutions are present, these are detailed in the response, accompanied by a has_more indicator to signal the presence of further solutions.

has_more: true
results:
- substitutions:
  - expression: a1
    variable: X
- substitutions:
  - expression: a2
    variable: X
variables:
- X

Error

If an error arises while searching for solutions, the search process is halted and the error is reported as part of the solutions list. As a result, the error field is no longer included at the response level.

results:
- substitutions:
  - expression: a1
    variable: X
- substitutions:
  - expression: a2
    variable: X
- error: error(existence_error(procedure,throw/1),foo/1)
variables:
- X

Consequences

Positive

• Unified Outcome Handling: All results, including errors, are handled uniformly.
• Partial Successes: Allows for the capture and use of successful results found before an error.

Negative

• Introduces a breaking change
• Increased Client Complexity: Clients must inspect each solution for errors, complicating error handling.

Neutral

None

Request for community feedback 🤗

We seek input on the following:

• Experiences or concerns regarding each response format.
• Alignment of these formats with your usage expectations or needs.
• Requirements for a response format from a developer's perspective.

Any additional suggestions or ideas for alternative response formats or enhancements.

Future Actions 🚀

We invite all community members to contribute their insights, experiences, and recommendations regarding this topic. Your participation is invaluable in shaping the evolution of the Logic module's response formats, ensuring they meet the diverse needs and expectations of everyone.

[amimart]

Here are the remarks I may have on this topic

Response format

Providing both success and error is redundant, keeping only the error field looks good to me.

Partial success

On the matter of exposing partial results in case of an error I don't have a precise opinion, I'm navigating between two point of views:

• It allow to manage a partial success on the client side;
• An error could indicate the results may be wrong, so using the outcome could be dangerous;

But maybe this judgement should precisely be the responsibility of the client.. I'm parted but I have no contraindication so I'll stay neutral and put my trust in @ccamel :).

[ccamel]

Thanks @amimart for your insightful feedback. I believe we can proceed with this proposal. We'll see in practice if the defined framework meets all the needs, especially those of the builder community.

[ccamel]

Implemented by axone-protocol/axoned#575.