Longer transactions don't get signed

Hello, it appears that longer transactions don’t get signed by the Fireblocks. In the following code:

const transaction = await this.client.createTransaction({
    operation: TransactionOperation.RAW,
    source: {type: PeerType.VAULT_ACCOUNT, id: '0'},
    assetId: 'HBAR_TEST',
    extraParameters: {rawMessageData: {messages: [{content: message}]}}
});

when message value is {"test": "test"} the request returns correctly signed data:

When we use realistic value (with a different size) such as:

{"id":"85202d35-ecfa-4a2a-988b-83db7de96a77","status":"ISSUE","type":"Topic","action":"create-topic","lang":"en-US","name":"SCHEMA_TOPIC","description":"SCHEMA_TOPIC","owner":"did:hedera:testnet:E2pCYYGiXR3rSEMtc95xr2YNP3P2jyTyM4GXpsN836LR_0.0.3691957","messageType":"SCHEMA_TOPIC","childId":null,"rationale":null}

it does not sign the message and returns no error (see next post)

image

@mnamakwala Appologies for tagging you directly, but my request has had no response for a week. Is there any chance you can verify this for us please?

Hey Andrew,
I will take a look into this for you.
Can you please provide a tx id for these two RAW transactions?

Hi @mnamakwala, I hope you had a good week-end. Just reaching out to see if there’s been any progress on this?

Hey Andrew,
Can you please provide some examples of failed transaction IDs?
So I can investigate.

We do have a limit too.
You can aggregate a maximum of 127 messages for Raw Signing.

Hi @mnamakwala , thank you - I will get you the transaction ID tomorrow. Just a note, we only send a single message so we don’t exceed the 127 threshold at all.

Yes please send in a transaction id, and I will check it.
Thanks.

The transaction ID was: dbe61c38-b485-4a11-aceb-96e7beb7018b. Hopefully you can help us! @mnamakwala

Hi Andrew,
I can see that tx dbe61c38-b485-4a11-aceb-96e7beb7018b was signed and the signature was sent.
You should be able to find the signature in messages in the field “fullsig”
Thanks

Hello @mnamakwala, thank you for your answer - we checked and indeed the result for the above-mentioned tx is available now. However it was not available then - in the immediate response which was confusing.

We have now experimented with other variants of the same and determined that API seems to provide ‘answers’ with a delay - e.g. in each case we needed to poll for the answer and eventually the result came back. In our tests with small payloads we’ve seen such delays of around 8 seconds (we polled multiple times with 2 secs intervals) - is this expected? Is this what we supposed to do - i.e. we should keep polling until the result come back? Is there a webhook or other similar facility we can use instead of polling?

Yes, we do have a webhook feature. Please check out the article below about it.

The payload size does not matter and should not affect the time required to sign a message.
If there is more than one message.
It might take more time.