Truffle cannot migration with the latest Geth 1.8 #721
Comments
|
I have the same issue. It happens when Truffle tries to get the recipient of the transaction. |
|
Fixed in this commit https://github.com/ethereum/go-ethereum/pull/15714/files |
|
I'm still having this issue. |
|
I have the same problem. My contracts don't change but now migrations don't work with above error. Do you have any update of this issue? |
|
same issue , who can help me |
|
same issue, cant deploy my contracts to rinkeby network. |
|
Having the same error inside our app when running on Rinkeby with Geth built from |
|
Having the same problem when deploying contracts to a private geth node built off 1.8.0-unstable. It fails after a response from the geth node. What is interesting is that if I only deploy 1_initial_migration.js without any other follow-up migrations, no error occurs. |
|
Having the exact same issue also on geth 1.8.0-unstable. Was rectified by using geth 1.7.3. |
|
@hickscorp After trying lots of stuff, I got it past migration successfully by running miner.start() on the node that I am deploying the contract on. This seems to solve this issue. |
|
@ahester57 Being able to get past it with an active mining process is a bi-product of something else. |
|
@hickscorp This is actually on 1.7.3-stable as well. When deploying a newly initialized contract using truffle, it stalls right at the first migration, unless the node is mining. |
|
@ahester57 Well that's not new, and unrelated to the issue here. "Deploying" is just asking for data to be mined. I'd recommend you having a look at this tool. This is what we use to have "on-demand" mining local nodes with 0-difficulty, so our CPU just doesn't get busy non-stop. |
|
seeing the same issue here |
|
Same issue here.
|
|
I'd like to emphasize something here, what @ahester57 said about this problem being present on 1.7 is erroneous, it's a completelly different thing he's describing, not even an error (No transaction can be mined... Unless the node is mining). The 1.8 problem is indeed not solved by mining. |
|
Same issue while trying to deploy on Rinkeby testnet with: |
|
@darioAnongba I think you might be confused here. It works fine with Rinkeby. It just doesn't work with geth 1.8, those are two different things. Your question might instead be "What I don't understand is why is it working fine with Ganache and not with Geth 1.8?", and the answer would be that Geth is just an implementation of Ethereum, while Ganache is another, and while Ganache returns something that Truffle expects during the migrations as well as Geth 1.7, Geth 1.8 doesn't. Therefore, using Geth 1.7 you should get it to work regardless of the network you're deploying to. |
|
Thanks @hickscorp ! So if I understand correctly, Truffle is just not compatible with geth 1.8 yet. |
|
I'm encountering this issue as well. I've installed a private blockchain using geth 1.8 and am also encountering the Can this be given priority given 1.8 is now out? https://blog.ethereum.org/2018/02/14/geth-1-8-iceberg%C2%B9/ Some additional notes:
|
|
@hickscorp Thanks so much for all your work on this issue, much appreciated. |
|
@cgewecke Don't mention it. It's worth noting that I've started talking to the Geth devs, but I don't think it's a bug as per say, it's more likely a different behaviour that Truffle would have to accomodate for. Tell me if you need anything else. I would say that this now might need a bit of attention from the devs, as @starlabs007 pointed out 1.8 has been out for a small while now. Keep up the good work ;) |
|
truffle-contract 99 contains a small fix for this. Not sure when our next patch release will be but should be resolved then. |
|
https://github.com/ethereum/go-ethereum/releases/tag/v1.8.1 |
|
@vecheslav I just tested 1.8.1, still errored. Downgrading to 1.7.3 seems to be the way to go for now. Here are some easy instructions for those who are desperate to deploy a contract. OSX only, though it would be similar on other OSs. # OSX instructions to get 1.7.3
git clone [email protected]:ethereum/go-ethereum.git;
cd go-ethereum;
git checkout tags/v1.7.3; # checkout 1.7.3
# brew switch go 1.9.4; # install a version of go that 1.7.3 is happy with.
make geth;
ln -s ${PWD}/build/bin/geth /usr/local/bin/geth-173; # or geth if you want to use it in scripts etc...
geth-173 version; # version checkI had a hard time getting it to install with go 1.10 because make checks the version of go, and doesn't properly sort the versions. It things 1.10 < 1.7. So if EDIT: forgot to checkout the right version in the script. |
|
@cgewecke I'm not sure why this is closed? Was some progress made? |
|
You should checkout appropriate branch
and compile this one
|
|
I can deploy fine but any contracts method transactions fail. Rolled back to geth 1.7.3 fixed it. |
|
Any plan to support new geth ^1.8? Or we need to rollback to ^1.7? |
|
@lerer00 There's a fix for this at truffle-contract 99 that should be released next Monday. |
|
@cgewecke sweet thanks for the info. |
|
How to roll back to 1.7.3? |
|
Pls suggest what is fix for this am also using Geth 1.8.1 and Truffle 4.0.6. Error encountered, bailing. Network state unknown. Review successful transactions manually. |
cgewecke
changed the title
|
@marshaln Downgrade to 1.7.3 and watch this issue for when it's fixed |
|
@marshaln The fix for this is not to downgrade. The fix is to be mining on
the node you're migrating to. I had some backlash after I suggested this
earlier since it's a separate issue, but it is the only way I am able to
migrate contracts successfully to geth. Some people may not know you have
to be mining, and if this isn't true, then please provide some evidence
that we are able to deploy a contract on a light node.
…On Feb 24, 2018 00:22, "marshaln" ***@***.***> wrote:
Pls suggest what is fix for this am also using Geth 1.8.1 and Truffle
4.0.6.
Contracts are deploying but .json file is not updated in build/contracts
folder.
Error encountered, bailing. Network state unknown. Review successful
transactions manually.
Error: unknown transaction
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#721 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ARya1fVjFCRGGVJbZ7FhDFNcBM0cgfCVks5tX6qSgaJpZM4RDt8z>
.
|
|
@ahester57 If you're mining on Ropsten with a CPU it might take a while to migrate/mine a tx, right? Probably more than the timeout? Mining also used to not be necessary and is wasteful on testnets. So having to mine on a testnet instead of just connecting to a node to submit a tx or contracts seems to be a step backwards. |
|
@JohnAllen Downgrading is two steps backward, in my opinion. |
|
I'm sure they'll fix this, but not having to mine and run CPUs up (even with |
|
You can't mine on rinkeby, which is a testnet I use often for simplicity. Ropsten is better, but it's more annoying also. I like to start with rinkeby. |
|
@ahester57 There's a fix for this at truffle-contract 99 that should be released next Monday. |
|
4.0.7 is out and there's a confirmed success deploying with Geth 1.8 to Rinkeby from Gitter. There's also a confirmed 'having problems' on Ropsten. Feel free to report any developments here or on Gitter. We're also releasing tomorrow so if the current fix doesn't work, we'll have a chance to update it and try again shortly. |
|
@hickscorp Closing because we think this is fixed in |
* working anchor prototype * working anchor prototype * testing out how to get the correct transaction ID from client to assure acceptance of data * working 'integration test' setup with bindings from 1.7.3 * adding geth tooling scripts * upgrading to go-ethereum 1.8 and testing * adding go172 launch script as workaround for trufflesuite/truffle#721 * working 'integration test' to subscribe to logs/events * working version with channel pass-through * allowing to run eth commands from any directory * faster block time for geth * easier unit testing for anchoring. adding string tools. * fix witness code to run tests * more unit testing * adding tests for tools package * configuration for get_client coming from viper again * anchor registry configurable through env vars * support multiple eth accounts, start concurrency handling in eth client * make eth client init thread safe * clean up anchor creation safety, start concurrency handling * add: comments, contextWaitTimeout as configuraton. fix: genesis file, mod: filter anchor registered event by "from" address
|
Small update: This is fixed at Geth as well as of 1.8.2 (released this morning). Geth no longer errors with 'unknown transaction'. |
|
Confirmed working with geth 1.8.1 on a non-mining node as well. No more
throwing 'network unknown.'
…On Mar 5, 2018 11:54, "c-g-e-w-e-k-e->" ***@***.***> wrote:
Small update: This is fixed at Geth as well as of 1.8.2 (released this
morning). Geth no longer errors with 'unknown transaction'.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#721 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ARya1SjB5CJcpH5Fd8i2n43gBLtgAP1sks5tbXvIgaJpZM4RDt8z>
.
|
|
Geth 1.8.1. Worked fine till yesterday. Error started appearing consistently for rinkeby and from time to time with ganache. Upgrade to 1.8.2 didn't fixed the issue. |
|
Upgraded my Truffle to 4.1.3 and it solved the problem (was on 4.0.6). |
|
Just test Truffle 4.0.6 and Geth 1.8.2-stable. Deployment now works. @ahester57 Yes, also keep mining.😼 |
|
Upgrading [email protected] to + [email protected] works for me 👍 |
and others
Issue
When using the latest
geth-unstablefrom the official debian ethereum repo (http://ppa.launchpad.net/ethereum/ethereum/ubuntu artful main), Truffle fails with even the most basic migrations.It is worth noting that:
gethpackage1.7.3-stable.geth-unstablepackage1.8.0-unstable.Steps to Reproduce
Create the most simplistic project with only the
Migration.solcontract and a migration to deploy it. Runtruffle migrate --network geth, assuming that you configured agethnetwork somewhere in yourtruffle.js. Mine looks like so:I'm using a set of scripts to get Geth to run correctly.
Expected Behavior
A successful migration with the last ID published.
Actual Results
Environment
4.0.3, same issue with4.0.1.8.9.15.6.0The text was updated successfully, but these errors were encountered: