Project

General

Profile

Feature #11423

implement centralized status/error tracking for conversion/dev tools

Added by Greg Shah 3 months ago. Updated 3 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:

Related issues

Related to Conversion Tools - Feature #7180: create a centralized manager for the conversion list and per-file/project status and logging Closed
Related to Conversion Tools - Feature #3882: changes to allow the front-end to be used for 4GL syntax checking New
Related to Conversion Tools - Feature #11355: VSCode extension New

History

#1 Updated by Greg Shah 3 months ago

  • Related to Feature #7180: create a centralized manager for the conversion list and per-file/project status and logging added

#2 Updated by Greg Shah 3 months ago

  • Related to Feature #3882: changes to allow the front-end to be used for 4GL syntax checking added

#3 Updated by Greg Shah 3 months ago

#4 Updated by Greg Shah 3 months ago

  • Subject changed from implement centralized status/error tracking to implement centralized status/error tracking for conversion/dev tools

Current State

Our current approach to error handling is we write something to STDOUT or a log when a problem is detected. Sometimes we abort, sometimes not. That is basically it. You can't tell status without analyzing the logs. You don't get any feedback on how complete any given job is.

This is not OK.

Objectives

Create a central service which tracks:

  • Problems
    • Whenever something adverse occurs, it gets reported to the central service instead of being output to log.
    • We will standardize what is reported. This includes:
      • descriptions
      • error codes
      • severity levels
      • source code file and location (needs #3881)
      • profile
      • thread
    • Querying
      • At any time while a tool is running (e.g. a conversion job), the current list should be queryable.
      • The list should be available by different views:
        • Scope
          • By Artifact
          • By Directory
          • By Profile
          • By Project
        • Severity Level
        • Problem Type/Description/Error Code
  • Status
    • Each job being processed should record centralized status as it runs.
    • This would include things like:
      • Phase is being processed (e.g. annotations, core conversion).
      • Current profile, file being processed.
      • Rough % complete.

How We Will Use This

After this is implemented, I would expect that we would:

  • Rework Tools
    • Command line tools like ConversionDriver should not output logs by default, but instead should be reworked to provide a high level status as it processes and output a detailed error summary at the end.
    • The #3882 syntax checker would be implemented based on our front end conversion and this error/status tracker.
    • The #11355 IDE support would use this to drive the LSP "diagnostics".
  • Standardized configurable options should be provided for how we respond to errors. In particular, do we abort when we see a problem of a specific level?
  • When the job is full complete, we should be able to report an overall success/failure.

Also available in: Atom PDF