Return to Answer

It looks like this problem has been resolved.

This is fixed now. Sorry about that.

 

As part of a refactoring related to the new review UI, we started storing "rejection reason ids" with bytes instead of ints, and I failed to notice that we were representing "custom reason" with -1 on the client side (and bytes can't be negative).

It looks like this problem has been resolved.

This is fixed now. Sorry about that.

As part of a refactoring related to the new review UI, we started storing "rejection reason ids" with bytes instead of ints, and I failed to notice that we were representing "custom reason" with -1 on the client side (and bytes can't be negative).

It looks like this problem has been resolved.

This is fixed now. Sorry about that.

As part of a refactoring related to the new review UI, we started storing "rejection reason ids" with bytes instead of ints, and I failed to notice that we were representing "custom reason" with -1 on the client side (and bytes can't be negative).

It looks like this problem has been resolved.

This is fixed now. Sorry about that.

As part of a refactoring related to the new review UI, we started storing "rejection reason ids" with bytes instead of ints, and I failed to notice that we were representing "custom reason" with -1 on the client side (and bytes can't be negative).

It looks like this problem has been resolved.

 

This is fixed now. Sorry about that.

 

As part of a refactoring related to the new review UI, we started storing "rejection reason ids" with bytes instead of ints, and I failed to notice that we were representing "custom reason" with -1 on the client side (and bytes can't be negative).

It looks like this problem has been resolved.

 

This is fixed now. Sorry about that.

 

As part of a refactoring related to the new review UI, we started storing "rejection reason ids" with bytes instead of ints, and I failed to notice that we were representing "custom reason" with -1 on the client side (and bytes can't be negative).