Incorrect Type Definition of ChaincodeResponse

[Jerrylum]

Shim.success and Shim.error functions return SuccessResponse and ErrorResponse. The return types are defined using JSDoc and both type definitions are also defined using JSDoc in the same file.

However, for the TypeScript definition, ChaincodeResponse is used instead. It requires three properties including status, message, and payload. But both users Shim.success and Shim.error do not return an object with all three properties at the same time. In this case, I believe the type definition of ChaincodeResponse is incorrect.

[bestbeforetoday]

I agree. Perhaps the TypeScript types would be better defined like this?

interface SuccessResponse {
    status: RESPONSE_CODE.OK;
    message?: string;
    payload: Uint8Array;
}

interface ErrorResponse {
    status: RESPONSE_CODE.ERROR;
    message: string;
    payload?: Uint8Array;
}

type ChaincodeResponse = SuccessResponse | ErrorResponse;

export class Shim {
    static error(msg: Uint8Array): ErrorResponse;
    static success(payload?: Uint8Array): SuccessResponse;
    // ...
}

So any fix can properly address your issue, I'm interested to know the impact of this typing mismatch on your use of the API.

[Jerrylum]

I think the fix could be the following:

interface SuccessResponse { // <- message is unnecessary for SuccessResponse 
    status: ChaincodeStub.RESPONSE_CODE.OK;
    payload: Uint8Array;
}

interface ErrorResponse { // <- payload is unnecessary for ErrorResponse 
    status: ChaincodeStub.RESPONSE_CODE.ERROR;
    message: string;
}

type ChaincodeResponse = SuccessResponse | ErrorResponse;

export class Shim {
    static error(msg: string): ErrorResponse; // <- this should be string instead of Uint8Array
    static success(payload?: Uint8Array): SuccessResponse;
    // ...
}

I was writing test cases for my chain code and discovered the issue. Do you think we can make a pull request?

[bestbeforetoday]

Definitely you are correct that the error function should take a string parameter: error(msg: string): ErrorResponse.

The only slight concern is that the ChaincodeResponse returned from the ChaincodeInterface methods really can be anything that fits the shape:

interface ChaincodeResponse {
    status: number;
    message?: string;
    payload? Uint8Array;
}

However, this is really an implementation detail only affecting the low-level shim API for developing chaincode, and the values that actually make sense better fit your type definitions.

Please feel free to open a PR to modify the types as you've described.