dfuse Websocket API table signature shows: `SIG_K1_111111111111111...`

Question

Websocket push table: The content signature type is printed out like this. This table actually has a signature. What could be the possible reason for this to show up.

Update

How do I get this value/turn this into string field table？

This is my code:

websocket

client
  .connect()
  .then(() => {
    client.getTableRows({code:'pokereoshold', scope:'pokereoshold', table: 'gameinfo', json: true})
    .onMessage((message) => {
      if(message.data.dbop != undefined) {
        if (message.type === InboundMessageType.TABLE_DELTA) {
          if(message.data.dbop.new != undefined){
            console.log('222', JSON.stringify(message.data.dbop.new));
          }
        }
      }
    })；
  }).catch((error) => {
    console.log("Unable to connect to dfuse endpoint.", error)
  })

contract table structure
// @abi table gameinfo i64
struct gameinfo {
    account_name player;
    uint64_t bet_id;
    uint64_t bet_time;
    eosio::asset bet_amt;
    account_name referral;

    string seed;
    checksum256 seed_hash;
    signature sig;
    checksum256 sig_hash;

    vector<uint8_t> dealer_cards;
    vector<uint8_t> dealer_max_cards;
    vector<uint8_t> player_cards;
    vector<uint8_t> player_max_cards;
    vector<uint8_t> center_cards;

    uint8_t bet_result;
    uint8_t dealer_cardstype;
    uint8_t player_cardstype;

    eosio::asset payout;

    uint64_t primary_key() const { return player;};
    EOSLIB_SERIALIZE(gameinfo,(player)(bet_id)(bet_time)(bet_amt)(referral)(seed)(seed_hash)(sig)(sig_hash) \
    (dealer_cards)(dealer_max_cards)(player_cards)(player_max_cards)(center_cards)(bet_result)(dealer_cardstype) \
    (player_cardstype)(payout))
}; ```

Answer 1

This simply means the zero value for a signature. If you look at the packed data (the hexdata field), you should see a series of zeroes at that place.

Answer 2

There was a bug in dfuse API where signature binary data was not properly decoded leading to a default signature to be returned.

As of today (Januaray 20th, 2019), the bug has been fixed and deployed. So this should not happen anymore.