Error reporting

[svacina]

In case the repository we are analyzing does not comply with our requirements, please send json response with most likely set of violations:

• wrong annotations
• not a java project, etc..

It is a bigger issues, it overlaps with: #5

Please, get in touch on this with Vincent.

[vinbush]

@svacina @diptadas Here is my proposal for handling errors. Since the repositories we receive may have some microservices that match our requirements and some that don't, I think we shouldn't deny requests outright on a failing microservice. Rather, we should try to continue processing as much as we can and give errors on individual services:

1. If there is an error in processing (i.e. can't download repo), return a standard error format
2. If an individual microservice contains no supported entities, silently drop it from the result list
   • Alternatively, if we have easy access to a way to detect if the service is not a Java/Python project, we can silently drop the unsupported services, then display a message on the individual Java/Python projects saying, "No supported annotations found". Do we have that ability readily available?
3. If no entities are found (i.e. the context map is empty), display a message saying "No supported annotations found" in place of the context map
4. If no calls are detected (i.e. the communication diagram contains no edges), display message saying "No supported HTTP calls detected" in place of the communication diagram

Here is a general error format:

{
    "error" : true,
    "message" : "An error occurred while processing the repository: <some more information>"
}

And an updated response format showing the error states:

{
    "global": {
        "projectName": "tms",
        "hasCommunication" : false, // would be true if calls exist
        "communication": "",
        "hasContextMap" : false, // would be true if entities exist
        "contextMap": "",
    },
    "ms": [
        {
            "name": "servicename",
            "hasBoundedContext": false,
            "boundedContext": ""
        }
    ]
}

[vinbush]

@svacina I created a page in Notion showing the return formats, including error handling: https://www.notion.so/Prophet-Utils-App-9559cde5014e44ea94112e453681bdfb

The relevant classes for showing errors are:

• ProphetError for the general failure case
• ProphetAppGlobal contains booleans indicating if we were able to create a context map and/or communication diagram
• MicroserviceResult contains a boolean indicating if we were able to create a bounded context, plus a message giving the reason for failure if we couldn't make it

[svacina]

@vinbush
We need to have array of errors for both repository and microservice.
The most important errors are those associated with repository not with microservice.
Need to have better naming conventions in dto objects. Message is ambiguous. At least errorMessage.
Need to have list of actual errors we generate. What are they? Where are those checks implemented?

[vinbush]

@svacina What repository errors do you want to collect? The language and presence of usable annotations vary by microservice, and they can be different within a repository if it contains more than one microservice.