Replies: 6 comments 4 replies
-
The serializing in v5 is very strict, which was to prevent simple typos from generating wrong output, but it does mean some methods are not reflexive. This likely won’t be changed in v5, but in v6 things are much more relaxed, but easier to enforce as many things, like Transaction, are proper classes. If there is a strong need for this, I can internally validate the properties are consistent and drop them before serializing. There are a few other high-priority features though, such as eip-1559 support which is next on deck. |
Beta Was this translation helpful? Give feedback.
-
There's no strong need since it's easy to work around the issue, but it would be nice to have (in v6) for sure. |
Beta Was this translation helpful? Give feedback.
-
I'm noticing that it's also necessary to remove the |
Beta Was this translation helpful? Give feedback.
-
I'm going to move this to discussions for those who may also find it useful. The issues described here affect only v5 and below; v6 will have a more robust solution. :) |
Beta Was this translation helpful? Give feedback.
-
One big piece of information that seems to be missing from this conversation: It's possible to circumvent this issue by creating a new object from the old, leaving out the problematic properties. Here is how I was able to circumvent this issue: const deserializedTx = ethers.utils.parseTransaction(serializedTx);
console.log("deserializedTx: ", deserializedTx);
const testTx = {
data: deserializedTx.data,
to: deserializedTx.to,
chainId: deserializedTx.chainId
};
const txInfo = await wallet.sendTransaction(testTx); By creating a new object, and simply omitting the problematic properties, the transaction can be signed and broadcast. I'm a newbie to ETH stuff, so this was not obvious to me. |
Beta Was this translation helpful? Give feedback.
-
Is this new serialization method actually implemented in v6.3.x ? I have the same issue here, and I wonder if it's worth to migrate now... |
Beta Was this translation helpful? Give feedback.
-
Describe the bug
When using the
parse
function of@ethersproject/transactions
to parse a (legacy) transaction, trying toserialize
that transaction (using the same package) results in an error:This happens for both signed and unsigned transactions. I'm not sure if this is a bug, but it's definitely unexpected behaviour.
Reproduction steps
The following code will throw an error at
serialize
.Removing the signature and
type
before serializing works:Environment:
It happens both in Node.js (v14) and in a browser (tested in Chrome 90), using
@ethersproject/transactions
5.2.0.Beta Was this translation helpful? Give feedback.
All reactions