You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I'm having a weird issue where two tx ids are poiting to the same receipt, some context:
I made a tool to upload files, the tx of the upload is stored beforehand since it can be deduced based on the tags and anchor,
Basically this
Now for some reason, the second time I did this, the tx for the same file changed, it still fails when I try to upload with const receipt = await irys.uploadFile(path.join(dirPath, file.filename), { tags: tags, anchor: paddedAnchor });
But the transaction that it fails with is not the same that it generated beforehand.
These are the transactions
tx1 6MM7sei8s8g9PfjzShxdKrN9H6dxKRHW41qH87bXStF4
tx2 T4DMg1hT7mSldtqCRKi1PN1Lvvpdw08FRFsfR3nrPWM <-- this is the unexpected one.
Still, when I tried to see the receipt for the second transaction, it pointed to the first, so not sure what's going on.
This is the error I receive when trying to upload the file that the tool thinks should have the tx2. Error: Transaction 6MM7sei8s8g9PfjzShxdKrN9H6dxKRHW41qH87bXStF4 already received
Now if I'm deducing the transaction wrong, I still don't know why that transaction would point to tx1 in the first place.
Edit: So I found that a bunch of other files that I uploaded previously now changed the tx id as well, but somehow this new tx still resolves to the original receipt, is this normal?
Edit 3: I found that the first time I did the upload, the two transactions were already different, and this happens with one wallet, but with another wallet it gives the same transaction always.
The text was updated successfully, but these errors were encountered:
Ok I think the devnet is making some changes and now is returning the txid as a base58 string, I think that solves the mistery, but I'll leave this open if some dev wants to add some info.
hey @gbogarinb , this is probably a side effect of Devnet's transition from Base64url encoded txids to base58 encoded txids - as part of this logic, we implemented a conversion layer that tries to convert Base64url txids to base58 and vice versa if the provided txid doesn't provide results - which explains this behaviour.
Hi, I'm having a weird issue where two tx ids are poiting to the same receipt, some context:
I made a tool to upload files, the tx of the upload is stored beforehand since it can be deduced based on the tags and anchor,
Basically this
Now for some reason, the second time I did this, the tx for the same file changed, it still fails when I try to upload with
const receipt = await irys.uploadFile(path.join(dirPath, file.filename), { tags: tags, anchor: paddedAnchor });
But the transaction that it fails with is not the same that it generated beforehand.
These are the transactions
tx1 6MM7sei8s8g9PfjzShxdKrN9H6dxKRHW41qH87bXStF4
tx2 T4DMg1hT7mSldtqCRKi1PN1Lvvpdw08FRFsfR3nrPWM <-- this is the unexpected one.
Still, when I tried to see the receipt for the second transaction, it pointed to the first, so not sure what's going on.
https://devnet.irys.xyz/tx/T4DMg1hT7mSldtqCRKi1PN1Lvvpdw08FRFsfR3nrPWM <-- I have no record of ever sending this transaction.
https://devnet.irys.xyz/tx/6MM7sei8s8g9PfjzShxdKrN9H6dxKRHW41qH87bXStF4 <-- I do see this one in my logs.
This is the error I receive when trying to upload the file that the tool thinks should have the tx2.
Error: Transaction 6MM7sei8s8g9PfjzShxdKrN9H6dxKRHW41qH87bXStF4 already received
Now if I'm deducing the transaction wrong, I still don't know why that transaction would point to tx1 in the first place.
Edit: So I found that a bunch of other files that I uploaded previously now changed the tx id as well, but somehow this new tx still resolves to the original receipt, is this normal?
Edit 2: My dependencies.
Edit 3: I found that the first time I did the upload, the two transactions were already different, and this happens with one wallet, but with another wallet it gives the same transaction always.
The text was updated successfully, but these errors were encountered: