If the user-provided log appears to be in the CSV format, we try to parse it using Elasticsearch's csv processor. In case of any resulting pipeline errors, we bubble up an error to the user, passing the additional attributes of an error – in this case, the original CSV error. This is how this error message appears to the user:
The error message is composed on the client side.
Action Items
The error message consists of a fixed part and the reference to a CSV processing error. Perhaps this can be better described in the UI.
It would be useful to include – as an additional technical detail available for advanced users – the line and column of the error source, and perhaps the original text as well.
It may not always be desirable to stop the generation process when a real log can have some lines that are not parsed correctly. Perhaps the user will prefer to continue the process and generate an integration that will skip these specific failed documents.
Context
If the user-provided log appears to be in the CSV format, we try to parse it using Elasticsearch's
csv
processor. In case of any resulting pipeline errors, we bubble up an error to the user, passing the additional attributes of an error – in this case, the original CSV error. This is how this error message appears to the user:The error message is composed on the client side.
Action Items
The error message consists of a fixed part and the reference to a CSV processing error. Perhaps this can be better described in the UI.
It would be useful to include – as an additional technical detail available for advanced users – the line and column of the error source, and perhaps the original text as well.
It may not always be desirable to stop the generation process when a real log can have some lines that are not parsed correctly. Perhaps the user will prefer to continue the process and generate an integration that will skip these specific failed documents.