stack empty when generating USFM

[johnml1135]

serval-api <info> info: Serval.Shared.Controllers.ErrorResultFilter[0]
      Client ZVFeO8livsYcjG8P7zX7eDParKlaNRHN@clients made request:
       {
        "action": "GetPretranslatedUsfm",
        "controller": "TranslationEngines",
        "id": "665a88edec58cd36956eacd1",
        "corpusId": "665a88efec58cd36956eacd4",
        "textId": "2CH",
        "version": "1"
      }.
       Serval responded with code 400. Trace: 00-fea063d359efb1f7fe48d6e9e3910e17-cea21f39df5fe253-00

There are a few issues:

• The USFM error is not fully spelled out in the logs or in the HTTP response (is there a better one than 400? Should we have a json error format?)
• It is crashing when it should not (likely). Duplicate verses in 20:34?
• Give an option to use the source USFM format? @pmachapman what do you think?

[pmachapman]

Give an option to use the source USFM format? @pmachapman what do you think?

@johnml1135 Would this be when generating a build, or when retrieving the USFM? Perhaps the only (non-technical) blocker I can see is that the user wouldn't know that they should use the source USFM or the target USFM.

For instance, for one user, their chapter 2 and 3 of a particular target book had no verse numbers whatsoever. From their perspective they expected those verse to be filled in by Serval/SF. Perhaps if certain errors, or pre-liminary check failures are encountered, Serval rather than throwing an error could retry with the source USFM? Or is that perhaps impractical?

[johnml1135]

I would rather have a flag that is set to do that - I don't like hidden features - if it fails it just "magically" uses the source USFM without telling you that it is. If I give you another flag such as useSourceUSFMTemplate (which defaults to false), then if it fails, you would be able to call it again requesting it from the source USFM and then inform the user in whichever way you deem best.

[pmachapman]

you would be able to call it again requesting it from the source USFM and then inform the user in whichever way you deem best.

@johnml1135 OK, we can do that. If possible, could we have a specific documented error code number (4XX or 5XX) from Serval when we encounter these errors? That would make the error catch at our end more understandable for people diagnosing why SF ends up calling the Serval API again with a different parameter.