Indexing stuck at one reinscription curse. Should have the ability to ignore the error and continue indexing.

[tiehoo]

Dear team,
I am new to ordinal world, trying to build a project based on ordhook. I am using ordhook-cli 2.0.0.

While running following command:
ordhook db sync --config-path=./OrdhookTest.toml

I got an error as following the process just stuck there forever, is there any workaround that I can let the process ignore that curse and continue syncing the db? Thank you very much!
I noticed 2 interesting point:

1. The current btc testnet block height=2816450, but I see in the error message: ordinal_block_height: 292362 which is in the future, that is very confusing to me. I checked the inscription_id in hord.sqlite, that inscription_id was inscribed at block 2815540. And the db sync is stuck at block #2815541.
2. The classic ordinal number is a negative number: classic: -2789

Here is the error log:
May 19 21:04:55.323 WARN unable to insert inscription in hord.sqlite: UNIQUE constraint failed: inscriptions.inscription_id - OrdinalInscriptionRevealData { content_bytes: "0x406d6f746f3a737761703a3a636272632d32303a737761703f61623d50495a5a412d5741474d4926613d3126623d302e3030303030313433", content_type: "text/plain", content_length: 56, inscription_number: OrdinalInscriptionNumber { classic: -2789, jubilee: 54631544 }, inscription_fee: 4550, inscription_output_value: 330, inscription_id: "0a7a4676da36cecae5591dd557d73d04ff8b0a3ad95dd09add86b5d00d32e9a1i0", inscription_input_index: 0, inscription_pointer: None, inscriber_address: Some("tb1pffdrehs8455lgnwquggf4dzf6jduz8v7d2usflyujq4ggh4jaapqpfjj83"), delegate: None, metaprotocol: Some("@Moto:swap::cbrc-20:swap?ab=PIZZA-WAGMI&a=1&b=0.00000143"), metadata: None, parent: None, ordinal_number: 1255906114357361, ordinal_block_height: 292362, ordinal_offset: 1114357361, tx_index: 1023, transfers_pre_inscription: 692, satpoint_post_inscription: "0a7a4676da36cecae5591dd557d73d04ff8b0a3ad95dd09add86b5d00d32e9a1:0:0", curse_type: Some(Reinscription) }

[lgalabru]

Thanks for your feedback @tiehoo. I'll close this issue, as we're already tracking this problem here: #292.