near-indexer-for-explorer
near-indexer-for-explorer copied to clipboard
near
Diesel migration run fails with "error applying hunk #1"
I have tried to build the indexer - following the steps:
git clone [email protected]:near/near-indexer-for-explorer.git cd near-indexer-for-explorer echo "DATABASE_URL=postgres://xxx:yyy@zzzz/dbdbdbd" > .env cargo install diesel_cli --no-default-features --features "postgres" diesel migration run
With the latest master commit, diesel migration run fails:
Running migration 2021-10-04-100000_assets_nft Running migration 2021-10-14-180948_add_resharding_state_change_reason_kind Running migration 2022-01-12-100000_assets_ft Running migration 2022-01-26-184200_drop_duplicated_index_execution_outcome Running migration 2022-01-26-184201_index_action_receipt_actions Running migration 2022-06-07-000000_drop_action_receipt_actions_args_amount_index Running migration 2022-08-12-123800_ft_nft_indexes error applying hunk #1
Versions:
OS: Ubuntu 20.04.5 LTS diesel 2.0.0 rustc 1.63.0 (4b91a6ea7 2022-08-08)
Hi, @sotcsa thanks for raising this. Were you able to work around the issue? If you did, please feel free to submit a request. Meanwhile, we will put this on our backlog.
@sotcsa hey there! Could you tell me what version of PostgreSQL do you use?
FYI, I've tried to apply the migrations on the newly created database locally and couldn't reproduce the bug.
I am using PostgreSQL 14.4
diesel migration run 07:50:02
Running migration 2020-12-07-153402_initial_schema
Running migration 2021-01-14-170424_index-receipt-originated-from-transaction-hash
Running migration 2021-01-20-152056_index-transactions-receiver-account-id
Running migration 2021-03-11-123839_index-action-kind-and-status
Running migration 2021-04-22-090505_execution_outcomes_replace_chunk_relation_with_shard_id
Running migration 2021-04-28-154439_denormalize_action_receipt_actions
Running migration 2021-05-06-093622_additional_indexes_for_action_receipt_actions
Running migration 2021-05-07-115559_convert_args_base64_to_args_json
Running migration 2021-05-10-084700_indexer_on_args_field
Running migration 2021-05-27-154211_account_changes_unique_idx
Running migration 2021-06-02-173100_add_migration_state_change_reason_kind
Running migration 2021-08-02-183200_transactions_sorting_idx
Running migration 2021-08-04-151515_circulating_supply_table
Running migration 2021-08-06-123500_account_changes_ordering_column
Running migration 2021-08-11-163800_account_changes_ordering_idx
Running migration 2021-10-04-100000_assets_nft
Running migration 2021-10-14-180948_add_resharding_state_change_reason_kind
Running migration 2022-01-12-100000_assets_ft
Running migration 2022-01-26-184200_drop_duplicated_index_execution_outcome
Running migration 2022-01-26-184201_index_action_receipt_actions
Running migration 2022-06-07-000000_drop_action_receipt_actions_args_amount_index
Running migration 2022-08-12-123800_ft_nft_indexes
Hi @khorolets
PostgreSQL 12.12 (Ubuntu 12.12-0ubuntu0.20.04.1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, 64-bit
I can't identify a problem as I cannot reproduce it. Could you try to apply that failing migration manually by just copying the SQL query from the up.sql file directly to your database and see if there is any useful error
cc @telezhnaya
@sotcsa The error "error applying hunk #1" does not look like one Postgres could return. It sounds like patch error which I don't see a reason to get here. Please, check that you don't have any merge conflicts in the repo and provide the screenshots of the commands you run with their outputs as well as the git status output.
Migration looks good. Please copy-paste the SQL, run it manually, and provide the error here.
I got the same error on the lastest migration 2022-08-12-123800_ft_nft_indexes -> error applying hunk #1 . I tried to run that manually on Postgres by copy-pasting from up.sql and it worked.
Maybe the problem comes from the different ways of testing. We are using an empty database, with fresh checkout, and fresh diesel install. @telezhnaya could you please provide a detailed process of how we should install first time?
On my first message I added hoow I did it from scratch - and can't see anytime working:
git clone [email protected]:near/near-indexer-for-explorer.git
cd near-indexer-for-explorer
echo "DATABASE_URL=postgres://xxx:yyy@zzzz/dbdbdbd" > .env
cargo install diesel_cli --no-default-features --features "postgres"
diesel migration run
@sotcsa were you able to run the manual SQL command and post that cargo build --release?
I think issue #302 is also linked to this
I have the same problem Hello, I'm having trouble starting after upgrading near-indexer-for-explorer to version 0.10.23 The execution of sql is normal, but the execution of cargo build --release failed
OS: ubuntu 20.04 postgresql: 14 err.txt
@sundafa The issue you report seems to be completely different one. Try fresh checkout from master as our CI passes just fine.
@sotcsa were you able to run the manual SQL command and post that
cargo build --release?I think issue #302 is also linked to this
That issue is the very same, if I don't stop at the first error, got the same result with the cargo build.
Team, could you describe please how you tested it whether it's working or not? Do you use a fresh DB and clean checkout? Many thanks.
@frol
I tried to pull a fresh copy of the master branch and used docker postgres:latest. I confirm the same issue. Tested on two platforms
Ubuntu 22 and Mac OS M1
Step followed
git clone [email protected]:near/near-indexer-for-explorer.git
cd near-indexer-for-explorer
echo "DATABASE_URL=postgres://xxx:yyy@zzzz/db-name" > .env
cargo install diesel_cli --no-default-features --features "postgres"
diesel migration run
Just an update, I saw that when I try to run diesel migration run it fails with an error error applying hunk #1 and makes the src/schema.rs file blank. @sotcsa this is the reason for your cargo build to fail.
A temporary workaround
- As @frol suggested after
diesel migration runfails, copy past the failed migration manually by just copying the SQL query from the up.sql file directly to your database - Get the old copy of the schema.rs back from git history using
git checkout -- src/schema.rsand try running cargo build. This worked for me
Hi.
I have the same problem.
When i try to run
diesel migration run
I receive
Running migration 2021-08-02-183200_transactions_sorting_idx
Running migration 2021-08-04-151515_circulating_supply_table
Running migration 2021-08-06-123500_account_changes_ordering_column
Running migration 2021-08-11-163800_account_changes_ordering_idx
Running migration 2021-10-04-100000_assets_nft
Running migration 2021-10-14-180948_add_resharding_state_change_reason_kind
Running migration 2022-01-12-100000_assets_ft
Running migration 2022-01-26-184200_drop_duplicated_index_execution_outcome
Running migration 2022-01-26-184201_index_action_receipt_actions
Running migration 2022-06-07-000000_drop_action_receipt_actions_args_amount_index
Running migration 2022-08-12-123800_ft_nft_indexes
error applying hunk #1
If I try to run commands, stored in migrations/2022-08-12-123800_ft_nft_indexes/up.sql
Then I receiving these errors:
postgres=> CREATE INDEX assets__ft_contract_id_idx ON assets__fungible_token_events (emitted_by_contract_account_id);
ERROR: relation "assets__fungible_token_events" does not exist
postgres=> CREATE INDEX assets__nft_contract_id_idx ON assets__non_fungible_token_events (emitted_by_contract_account_id);
ERROR: relation "assets__non_fungible_token_events" does not exist
Does anyone from the community have time to look into why diesel CLI leads us into this problem state? It seems to be not reproducible on our end 🤔
Encountered this error today, seemed like diesel issue [1]. Installing version 1.2 of diesel fixed this issue for me.
[1] https://github.com/rust-lang/crates.io/discussions/5348
Facing the same issue on diesel-cli 2.0.1 and Postgres 15.
~/near-indexer-for-explorer$ cd database && diesel migration run
Running migration 2020-12-07-153402_initial_schema
Running migration 2021-01-14-170424_index-receipt-originated-from-transaction-hash
Running migration 2021-01-20-152056_index-transactions-receiver-account-id
Running migration 2021-03-11-123839_index-action-kind-and-status
Running migration 2021-04-22-090505_execution_outcomes_replace_chunk_relation_with_shard_id
Running migration 2021-04-28-154439_denormalize_action_receipt_actions
Running migration 2021-05-06-093622_additional_indexes_for_action_receipt_actions
Running migration 2021-05-07-115559_convert_args_base64_to_args_json
Running migration 2021-05-10-084700_indexer_on_args_field
Running migration 2021-05-27-154211_account_changes_unique_idx
Running migration 2021-06-02-173100_add_migration_state_change_reason_kind
Running migration 2021-08-02-183200_transactions_sorting_idx
Running migration 2021-08-04-151515_circulating_supply_table
Running migration 2021-08-06-123500_account_changes_ordering_column
Running migration 2021-08-11-163800_account_changes_ordering_idx
Running migration 2021-10-04-100000_assets_nft
Running migration 2021-10-14-180948_add_resharding_state_change_reason_kind
Running migration 2022-01-12-100000_assets_ft
Running migration 2022-01-26-184200_drop_duplicated_index_execution_outcome
Running migration 2022-01-26-184201_index_action_receipt_actions
Running migration 2022-06-07-000000_drop_action_receipt_actions_args_amount_index
Running migration 2022-08-12-123800_ft_nft_indexes
Running migration 2022-09-23-100000_index_action_receipt_actions_on_timestamp_and_order_index
Running migration 2023-02-02-100000_fungible_token_events_pk_changed
Running migration 2023-02-02-110000_non_fungible_token_events_pk_changed
Running migration 2023-02-28-160000_meta_tx
error applying hunk #1
For me, errors like this are triggered not by migrations, but by having a diesel.toml file that excludes certain tables. It just SEEMS like its a migration thing because schema.rs gets written to a file using diesel.toml when I run migrations.
But I can trigger it without any migrations by doing diesel print-schema
I can also turn it off by commenting out the patch_file command. So yeah, I guess it's a conflict between the altered schema and the patch file.
