Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

This document focuses on increasing the ability of PM to track unimplemented features as well as increase the information available to customers attempting to use unimplemented features.

Process changes for new implementation work

For many reasons, CRDB may choose to not include the entirety of a SQL feature within a given release. Recent examples include CTEs or Timetz. Each time a feature is implemented partially, or an engineer is aware that there may be user demand for more than what is being implemented, the error reported should include:

...

In some rare cases, errors may be produced on a code path that cannot propagate the error to the client. In that case, the principle outlined above still applies: the error should be registered internally inside the CockroachDB process in a place where the reporting loop can find it. The existing facility ((sql.Server).recordError or (Executor).RecordError) is suitable for this purpose. The error should also be logged (log.Errorf).

Upgrading errors with tracking labels to Github issues

Multiple places in the code already mark issues as unimplemented with a tracking label. Although this is sufficient to track attempts to use these features, it is not sufficient for users to understand the known limitation and learn about workarounds. For this purpose, the source code should be audited, and errors that only carry a reporting label should be upgraded to a link to a Github issue (including "docs-todo" and "known-limitation") that explains the limitation, provides some example of the unsupported forms, and if possible, examples of workarounds.

Multiple places in the code produce errors containing the text "unsupported" or "unimplemented" but not actually marked as an unsupported feature error that can be recognized by error tracking. For example:

...