namesys-eth / ccip2-eth-backend

Backend IPFS Service for CCIP2 Client
1 stars 0 forks source link

Unable to Update Records on app.namesys.xyz - 'Record Update Failed' Error Encountered #2

Closed Lakatoi closed 3 months ago

Lakatoi commented 6 months ago

When attempting to update any records on app.namesys.xyz, after signing the changes, I encounter the message 'Record Update Failed.' In the console, one can see the error: 'ERROR: Failed to write to CCIP2 backend.

sshmatrix commented 4 months ago

Hi, I think this is due to the update to our client. Best option is to reset all your records by using a new password. Are you are using IPNS as storage (Ownerhash or Recordhash feature)?

Lakatoi commented 4 months ago

I've set the Recordhash for the name and the Ownerhash for a subname. This issue occurs with both.

I reset the records with a new password, but the same problem persists.

Also, after attempting to change the record and encountering the error message, if I try to update it again, the app won't let me, saying that the record is not in sync. After refreshing, it says that there has been no change.

Lakatoi commented 4 months ago

I've set the Recordhash for the name and the Ownerhash for a subname. This issue occurs with both.

I reset the records with a new password, but the same problem persists.

Also, after attempting to change the record and encountering the error message, if I try to update it again, the app won't let me, saying that the record is not in sync. After refreshing, it says that there has been no change.

I don't know if it's relevant, but when trying to access the IPNS through IPFS returns 500 error.

sshmatrix commented 4 months ago

There is some deep issue with IPNS, as it turns out. Several tests are failing on IPNS side. We'll be debugging this exclusively next week. You can try lite.namesys.xyz in the meantime?

Lakatoi commented 4 months ago

There is some deep issue with IPNS, as it turns out. Several tests are failing on IPNS side. We'll be debugging this exclusively next week.

Ok, thanks!!

You can try lite.namesys.xyz in the meantime?

Sorry, I also get an error: POST https://ipfs.namesys.xyz:3003/write net::ERR_CONNECTION_REFUSED

0xc0de4c0ffee commented 4 months ago

@Lakatoi 🙏 sorry for this mix up.. 🖐️ I updated our shared IPFS nodes to match another gateway/project's requirements.. 😬

Lite app's ccip write looks ok.. but during IPFS write and IPNS republish there's more uncaught errors.

https://ccip.namesys.xyz/.well-known/eth/mtorra/address/60.json https://ccip.namesys.xyz/.well-known/eth/mtorra/www/address/60.json

We use that ccip subdomain as secondary/lite web2 gateway but our primary primary IPFS gateway is failing withERR_HTTP2_PROTOCOL_ERROR, & as per specs that resulting http error/status code must be >= 500 to trigger fallback/secondary gateway during ccip lookup.. & AFAIK such ssl/client side error types are not covered by ERC-3668/fallback specs.

@sshmatrix is after temp fix, but for long run we've to move almost all of our current backend logic to client side and prepare for ENS V2/L2s. We've to rebuild with minimum IPFS/IPNS services and web2/ccip gateways for indexing and fallback. We've few more active tests with MFS/IPLD storages (bit fun experiments @ https://github.com/namesys-eth/notapi-eth ) and better+more IPNS republishing services (https://ipns.dev).

__ @Lakatoi As you're already on github, we've more dev friendly resolver and cli/signer tool..

https://dev3.eth.limo/ || https://www.npmjs.com/package/dev3-eth

As default/demo it's free <github-id>.dev3.eth subdomain system paired with public .github.io pages. we only run a tiny web2 service to verify and generate a signed approval for that specific github id+ address. no strings attached after that approval.

eg, ENS subdomain : https://0xc0de4c0ffee.dev3.eth.limo/ ENS record : https://0xc0de4c0ffee.github.io/.well-known/eth/dev3/0xc0de4c0ffee/contenthash.json

You can then switch your domain.eth's to dev3 resolver, then run function setupYourENS(bytes32 _node, address _signer, string calldata _gateway, string calldata _fallback) in dev3 resolver once.

https://etherscan.io/address/0x37ca355e75a72F4f467f780916DdF5dD90A46592#writeContract#F9

Dev3 is more open and minimalist, so you can copy paste between sub/domains under same 2LD with same approved signer mtorra.eth => /.well-known/eth/mtorra/address/60.json \<*wildcard>.mtorra.eth => /.well-known/eth/mtorra/\<*>/address/60.json lakatoi.dev3.eth => /.well-known/eth/dev3/lakatoi/address/60.json

0xc0de4c0ffee commented 3 months ago

we've temp fix in place.. 🙏

image

For future, we've to allow end users to bring their own extra IPFS pinning & IPNS republishing service as fallback..