Table of Contents

Checklist

User Stories Documented
User Stories Reviewed
Design Reviewed
APIs reviewed
Release priorities assigned
Test cases reviewed
Blog post

Introduction

CDAP pipeline is composed of various plugins that can be configured by users as CDAP pipelines are being developed. While building CDAP pipelines, pipeline developer can provide invalid plugin configurations. For example, the BigQuery sink plugin can have schema which does not match with an underlying BigQuery table. CDAP pipeline developer can use new validation endpoint to validate the stages before deploying the pipeline. In order to fail fast, validation endpoint should return all the validation errors from a given stage when this endpoint is called.

Data pipeline app exposes various exceptions to plugins so that appropriate exception is thrown while validating the plugins. In future releases, new exception types can be introduced. When plugins with new exception types are pushed to hub, data pipeline artifacts need to be upgraded for every new type of exception that is introduced. This is because the validation exceptions are defined in the data pipeline app itself. A better approach would be to modify data pipeline app so that app artifacts do not need to be replaced for every new type of exception.

Goals

To fail fast, introduce a new api to collect multiple error messages from plugins at configure time
Decouple various validation exception types from data pipeline app
Instrument plugins to use this api to return multiple error messages for validation endpoint

User Stories

As a CDAP pipeline developer, I validate a stage, I expect that all the invalid config properties and schema fields are highlighted on CDAP UI with appropriate error message.
As a plugin developer, I should be able to use new validation exception types without replacing data pipeline app artifacts.

API Changes for Plugin Validation

Approach 1

Collect multiple errors from plugins

To collect multiple stage validation errors from the stage, StageConfigurer, MultiInputStageConfigurer and MultiOutputStageConfigurer can be modified as below. If there are any validation errors added to stage configurer, the pipeline deployment will fail and all the errors will be returned as a response to stage validation REST endpoint.

Code Block

language	java
title	StageConfigurer.java

public interface StageConfigurer {

  ...

  /**
   * add validation errors for this stage to the configurer if pipeline stage is invalid. 
   *
   * @param error {@link ValidationException} when a pipeline stage is invalid for any reason.
   */
  void addValidationError(ValidationException error);
}

Decoupling exception types from data pipeline app

A new ValidationException is introduced for plugin validation in data pipeline application. Note that this exception extends a RuntimeException Exception so that the actual line number at which the exception occurred does not get lost. This can be helpful for debugging. However, that would mean that It includes the type of the exception and any additional properties for that exception.

Code Block

language	java
title	ValidationException.java

/**
 * Represents some sort of error that occurred during validation.
 */
@Beta
public class ValidationException extends RuntimeExceptionException {
  private static final String TYPE = "ERROR";
  protected final Map<String, String> props = new HashMap<>();

  public ValidationException(String message) {
    super(message);
  }

  public ValidationException(String message, Throwable cause) {
    super(message, cause);
  }

  /**
   * Returns the type of the validation exception. Type has to be unique for every validation exception.
   */
  public String getType() {
    return TYPE;
  }

  /**
   * Returns additional properties for the error.
   */
  public Map<String, String> getProperties() {
    return props;
  }
}

A new CDAP module in hydrator repository will be introduced to add new exception types for plugins. Plugins will have this module as compile time dependency which means when a type of exception is added, plugins can leverage it by just installing the module locally. This will allow us to easily add more types of exceptions for plugin validations while removing a need to update data pipeline artifact for each new exception type. Below are some of the exception types that will be added to this module.

Code Block

/**
 * Represents some sort of error that occurred during stage validation.
 */
@Beta
public class InvalidStageException extends ValidationException {
  private static final String TYPE = "STAGE_ERROR";

  public InvalidStageException(String message, String stage) {
    super(message);
    props.put("stage", stage);
  }

  public InvalidStageException(String message, Throwable cause, String stage) {
    super(message, cause);
    props.put("stage", stage);
  }

  public String getType() {
    return TYPE;
  }
}

Code Block

language	java
title	InvalidStagePropertyException.java

/**
 * Represents invalid stage property error that occurred during stage validation.
 */
public class InvalidStagePropertyException extends InvalidStageException {
  private static final String TYPE = "INVALID_FIELD";

  public InvalidStagePropertyException(String message, String stage, String property) {
    super(message, stage);
    props.put("property", property);
  }

  public InvalidStagePropertyException(String message, Throwable cause, String stage, String property) {
    super(message, cause, stage);
    props.put("property", property);
  }

  public String getType() {
    return TYPE;
  }
}

Sources and sinks can have schema mismatch with underlying storage. A new type of exception can be introduced so that invalid schema fields can be highlighted when schema mismatch occurs:

Code Block

language	java
title	InvalidSchemaFieldException.java

/**
 * Represents schema mismatch that occurred during stage validation.
 */
@Beta
public class InvalidSchemaFieldException extends InvalidStageException {
  private static final String TYPE = "INVALID_SCHEMA";

  public InvalidSchemaFieldException(String message, String stage, String field) {
    super(message, stage);
    props.put("field", field);
  }

  public InvalidSchemaFieldException(String message, Throwable cause, String stage, String field) {
    super(message, cause, stage);
    props.put("field", field);
  }

  public String getType() {
    return TYPE;
  }
}

Below is sample usage of these exceptions in the plugins:

Code Block

@Override
public void configurePipeline(PipelineConfigurer pipelineConfigurer) {
  pipelineConfigurer.createDataset(conf.destinationFileset, FileSet.class);
  StageConfigurer stageConfigurer = pipelineConfigurer.getStageConfigurer();
  try {
    Pattern.compile(conf.filterRegex);
  } catch (Exception e) {  
    stageConfigurer.addValidationError(new InvalidStagePropertyException(e.getMessage(), "filterRegex"));
  }
  if (conf.sourceFileset.equals(conf.destinationFileset)) {
    stageConfigurer.addValidationError(new ValidationException("source and destination filesets must be different"));
  }
}

Approach 2

In Approach 1 the contract of getProperties() method is to return a Map<String, String>. For example, stage validation exception can include stage → stage_name as a key value pair in the properties map. This map will be included in the json response of validation endpoint along with type and message. This contract limits the type of properties that can be added to the json response. For example, when pipeline validation endpoint is implemented, the additional properties of an error may include non-string objects.

Another option is to return a StructuredRecord with additional properties. While StructuredRecord does not have any limitation on type of properties that can be returned in the json response, each specific exception will have to create a StructuredRecord with additional properties. Because of the limitation of above contract, using StructuredRecord to get exception properties is a better approach.

Code Block

language	java
title	ValidationException.java

/**
 * Represents some sort of error that occurred during validation.
 */
@Beta
public class ValidationException extends RuntimeException {
  ...
  /**
   * Returns additional properties for the error as a {@link StructuredRecord}. If there are no additional properties
   * for this error, then return null.
   */
  @Nullable
  public StructuredRecord getProperties() {
    return null;
  }
}

Below are the corresponding specific exception types that extends ValidationException:

Code Block

language	java
title	InvalidStageException.java

/**
 * Represents some sort of error that occurred during stage validation.
 */
@Beta
public class InvalidStageException extends ValidationException {
  private static final String TYPE = "STAGE_ERROR";
  private final Schema schema;
  private final StructuredRecord record;

  public InvalidStageException(String message, String stage) {
    super(message);
    schema = Schema.recordOf("StageError", Schema.Field.of("stage", Schema.of(Schema.Type.STRING)));
    record = StructuredRecord.builder(schema).set("stage", stage).build();
  }

  public InvalidStageException(String message, Throwable cause, String stage) {
    super(message, cause);
    schema = Schema.recordOf("StageError", Schema.Field.of("stage", Schema.of(Schema.Type.STRING)));
    record = StructuredRecord.builder(schema).set("stage", stage).build();
  }

  @Override
  public String getType() {
    return TYPE;
  }

  @Nullable
  @Override
  public StructuredRecord getProperties() {
    return record;
  }
}

Code Block

language	java
title	InvalidSchemaFieldException

/**
 * Represents schema mismatch that occurred during stage validation.
 */
@Beta
public class InvalidSchemaFieldException extends ValidationException {
  private static final String TYPE = "INVALID_SCHEMA";
  private final Schema schema;
  private final StructuredRecord record;

  public InvalidSchemaFieldException(String message, String stage, String field) {
    super(message);
    schema = Schema.recordOf("InvalidSchema",
                             Schema.Field.of("stage", Schema.of(Schema.Type.STRING)),
                             Schema.Field.of("field", Schema.of(Schema.Type.STRING)));
    record = StructuredRecord.builder(schema)
      .set("stage", stage)
      .set("field", field)
      .build();
  }

  public InvalidSchemaFieldException(String message, Throwable cause, String stage, String field) {
    super(message, cause);
    schema = Schema.recordOf("InvalidSchema",
                             Schema.Field.of("stage", Schema.of(Schema.Type.STRING)),
                             Schema.Field.of("field", Schema.of(Schema.Type.STRING)));
    record = StructuredRecord.builder(schema)
      .set("stage", stage)
      .set("field", field)
      .build();
  }

  @Override
  public String getType() {
    return TYPE;
  }

  @Nullable
  @Override
  public StructuredRecord getProperties() {
    return record;
  }
}

Code Block

/**
 * Represents invalid stage property error that occurred during stage validation.
 */
public class InvalidStagePropertyException extends ValidationException {
  private static final String TYPE = "INVALID_FIELD";
  private final Schema schema;
  private final StructuredRecord record;

  public InvalidStagePropertyException(String message, String stage, String property) {
    super(message);
    schema = Schema.recordOf("InvalidField",
                             Schema.Field.of("stage", Schema.of(Schema.Type.STRING)),
                             Schema.Field.of("property", Schema.of(Schema.Type.STRING)));
    record = StructuredRecord.builder(schema).set("stage", stage).set("property", property).build();
  }

  public InvalidStagePropertyException(String message, Throwable cause, String stage, String property) {
    super(message, cause);
    schema = Schema.recordOf("InvalidField",
                             Schema.Field.of("stage", Schema.of(Schema.Type.STRING)),
                             Schema.Field.of("property", Schema.of(Schema.Type.STRING)));
    record = StructuredRecord.builder(schema).set("stage", stage).set("property", property).build();
  }

  @Override
  public String getType() {
    return TYPE;
  }

  @Nullable
  @Override
  public StructuredRecord getProperties() {
    return record;
  }
}

Conclusion

Approach 2 provides better representation of exception properties and does not impose any limitation on type of properties.

Impact on UI

UI should be able to handle new error types that are introduced. For example, for invalid stage properties, UI should highlight all the invalid properties for a given stage. For schema mismatch, UI should be able to highlight schema fields that are mismatching.

Below are the responses to the validation endpoint for each type of exception:

Type	Description	Json Response
STAGE_ERROR	Represents validation error while configuring the stage	`{` `"type"` `:` `"STAGE_ERROR",` `"stage"` `:` `"src",` `"message"` `: "source and destination filesets must be different"` `}`
INVALID_FIELD	Represents invalid configuration property	{ "type" : "INVALID_FIELD", "stage" : "src", "message" : "Invalid config for property 'port'", "property" : "port" }
INVALID_SCHEMA	Represents invalid schema field	{ "type" : "INVALID_FIELD", "stage" : "sink", "message" : "Invalid schema for the field 'name'", "field" : "name" }
PLUGIN_NOT_FOUND	Represents plugin not found error for a stage	{ "errors": [ { "stage": "src", "type": "PLUGIN_NOT_FOUND", "message": "Plugin named 'Mock' of type 'batchsource' not found.", "pluginType": "batchsource", "pluginName": "Mock", "requestedArtifact": { "scope": "USER", "name": "app-mocks-ghost", "version": "1.0.0" }, "suggestedArtifact": { "scope": "USER", "name": "app-mocks", "version": "1.0.0" }, } ] }

Test Scenarios

Test ID	Test Description	Expected Results

Versions Compared

Old Version 18

New Version 19

Key

Introduction

Goals

User Stories

API Changes for Plugin Validation

Approach 1

Collect multiple errors from plugins

Decoupling exception types from data pipeline app

Approach 2

Conclusion

Impact on UI

Test Scenarios

Releases

Release 6.1.0

Related Work

Future work

Page Comparison

Versions Compared

Old Version 18

New Version 19

Key

Introduction

Goals

User Stories

API Changes for Plugin Validation

Approach 1

Collect multiple errors from plugins

Decoupling exception types from data pipeline app

Approach 2

Conclusion

Impact on UI

Test Scenarios

Releases

Release 6.1.0

Related Work

Future work