-
Notifications
You must be signed in to change notification settings - Fork 199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should the contracts/search API error on unknown templates? #3771
Comments
There seem to be two mental models:
The argument for 1. is that it alerts users to mistakes. |
My preference would be option 1: Alert users. Let them fix the input. We can also:
|
Option 1 is already the model for the remainder of the query language, which is typed like the lf-value-json format; for example, if you specify |
There's at least one situation in which erroring out on a non-existent template is the wrong thing to do: Suppose you're upgrading an existing DAML model and hence need to support two versions of the model in your UI. At some point, all contracts of the old model will have been upgraded and you can garbage collect the old package from the ledger. The UI's queries to the JSON API would now start to fail for no good reason. I suggest we solve the problem by adding a flag to the query endpoint of the JSON API which determines what happens if you query for a non-existent template. In strict mode, you'll get an error, in lenient mode, you don't. I have no strong preference which is the default, although I'm leaning slightly towards lenient mode. |
I thought we can have a client-side logic that automatically removes non-existing template IDs. See what I proposed above, JSON API could report archived/non-existing template IDs, which client HAS TO remove from the request (can be done automatically). If we do not do this, we will accumulate a bunch of obsolete/archived template IDs over time. Which JSON-API will keep validating/resolving and skipping, increasing the request-response latency. In any case... to be honest we have a bigger problem. Which I think we have to address first. if you upgrade a template and don't change an entity name (e.g. don't add a suffix In other words if you have more than 1 template with the same |
IMO, making the package ids optional was a good idea in the first place. I don't see a big problem here though because you can just adopt a style of always using package ids, which is what the
How would the client-side know which packages are there and which aren't? If if there was a way to find this out without changing the client-side, this would add significant complexity on the client-side, partially defeating the purpose of the JSON API.
I think it's fair to assume that users are aware that they pay runtime costs for what they put in their queries. If they care about performance, they can clean up their queries. What would be the downside of making the behavior in case of non-existing template ids configurable? We can leave this out of the "simple documentation" of the JSON API and add it to an advanced section. |
you will receive a JSON output with an error that contains a variant describing that exact error scenario, and this variant will contain a list of unknown templateIds as they were passed from the client. Originally I thought we are talking about a search which is a part of some automated flow. From the above I understand you are referring to a manual search. So, what is wrong with asking a user to fix the search criteria because user specified an unknown template ID. As a user I would personally prefer to be notified that the template ID I am looking for does not exist any longer. Or just to know that there is a typo in one of my template IDs: In any case, if that is the behavior you want, talk with @bame-da and @da-tanabe, come up with something that makes everyone happy, document the requirements and prioritize this issue. I will be happy to work on it. |
the downside is complexity, we will have to support two modes and two sets of integration tests. |
How about JSON API returns HTTP 400, but with both results and errors for every unknown template ID. So you will have the data that JSON API was able to retrieve + error that tells user that they were searching for something that does not exist?
It will be up to the caller to decide what to do with the
|
What @hurryabit has said is exactly what I would have said as well. In principle I should be able to write a web app and have no errors if I did everything correctly. My mental model is firmly in the camp of @bame-da's (2). |
I don't think we should have any switches. @leo-da 's always including |
I'm fine with always returning a list of template ids that could not be resolved. I suggest we use 200 as the HTTP status code if unresolved template ids are the only "error" (I rather consider them to be warnings). Otherwise, our users' users will start seeing errors in their browser console just because our users have cleaned up their ledgers. |
which is fine with me, you get an error, -- you refine your search criteria, else there will be no way for end users to get notified about the non existent template IDs (unless you try to submit a new contract for this non-existing template). It is just strange that you will be able to search for contracts using non-existing template ID, get HTTP 200/success in response... but if you try to submit a new contract with the same template ID you get an error saying you can't use this template ID any more! |
again, it is up to the person who implements the UI to handle the proposed use case when you get HTTP 400 with both results and errors, if you think it is not an error, just don't display it, display only the results which may be empty if the only thing you specified is a non-existing template ID. If you are concerned about errors/warnings in the browser console, just do not log them. I don't think it is a default behavior to log 400. |
I would like to come to a conclusion about this ticket. Can we please implement the following behavior when you query for templates that don't exist:
|
|
What is code 101? |
custom error code/type guard. So you can match on it from TypeScript. Your
Is that fine?... or do you really want optional
|
I find this error code thing quite ad hoc. As I said before, I also regard it more as a warning and would prefer to not mix it up with actual errors. I'd very much prefer the optional |
|
[JSON API - Experimental] ``/contracts/search`` endpoint reports unresolved template IDs as warnings, see #3771:: { "warnings": { "unknownTemplateIds": ["UnknownModule:UnknownEntity"] }, "result": [{...}, ...], "status": 200 } CHANGELOG_END
[JSON API - Experimental] ``/contracts/search`` endpoint reports unresolved template IDs as warnings, see #3771:: { "warnings": { "unknownTemplateIds": ["UnknownModule:UnknownEntity"] }, "result": [{...}, ...], "status": 200 } CHANGELOG_END
[JSON API - Experimental] ``/contracts/search`` endpoint reports unresolved template IDs as warnings, see #3771:: { "warnings": { "unknownTemplateIds": ["UnknownModule:UnknownEntity"] }, "result": [{...}, ...], "status": 200 } CHANGELOG_END
…late IDs in the `warnings` element (#4014) * WIP * test cases updated * `PackageService.resolveTemplateId` returns `Option[TemplateId]` now used to return `Error \/ TemplateId`. There are scenarios when unresolved TemplateID is a warning and not an error, which was the initial design * CHANGELOG_BEGIN [JSON API - Experimental] ``/contracts/search`` endpoint reports unresolved template IDs as warnings, see #3771:: { "warnings": { "unknownTemplateIds": ["UnknownModule:UnknownEntity"] }, "result": [{...}, ...], "status": 200 } CHANGELOG_END * Addressing codereview comments * `partitionMap` is now part of `http.util.Collections.SeqOps`
I see both pros and cons. Please discuss.
The text was updated successfully, but these errors were encountered: