Make sequential blocks error configurable

[ra0x3]

• I've encountered our "Blocks not consecutive" error
• While it's nice to know this works! It should also be configurable
• I ran into this issue when running the QA suite
• I should be able to pass --nonsequential-blocks to the service (which is by default set to false) which will not enforce the sequential blocks error
• Without this the QA suite won't work

rk:80
2023-09-25T13:40:50.473691Z  INFO fuel_indexer::executor: 111: Indexer(fuellabs.explorer) will stop at block #335955.
2023-09-25T13:40:50.577759Z ERROR fuel_indexer::ffi: 229: Failed to put_object: Error from sqlx: Database(
    PgDatabaseError {
        severity: Error,
        code: "P0001",
        message: "fuellabs_explorer.indexmetadataentity: attempted to insert value with block_height = 325955 while last indexed block_height = 10000. block_height values must be consecutive.",
        detail: None,
        hint: None,
        position: None,
        where: Some(
            "PL/pgSQL function ensure_block_height_consecutive() line 8 at RAISE",
        ),
        schema: None,
        table: None,
        column: None,
        data_type: None,
        constraint: None,
        file: Some(
            "pl_exec.c",
        ),
        line: Some(
            3883,
        ),
        routine: Some(
            "exec_stmt_raise",
        ),
    },
)
2023-09-25T13:40:50.577905Z ERROR fuel_indexer::executor: 923: Indexer(fuellabs.explorer) WASM execution failed: Some blocks are missing.
2023-09-25T13:40:50.578144Z ERROR fuel_indexer::executor: 206: Indexer(fuellabs.explorer) terminating due to missing blocks.
Run(2/10) | Start: Block#325955 | Progress: 0/10000 (0.0%)^C2023-09-25T13:41:47.938014Z  INFO fuel_indexer::commands::run: 33: Received SIGINT. Stopping services.

[lostman]

@ra0x3, I'll add the option.

Meanwhile, this might be useful to you: the sequential blocks requirement does not mean that blocks must start at 1—the indexer's start block is configurable, after all. If you're starting QA tests in some block range, let's say 1-10,000, then you can restart the indexer at a different range, say 100,000-110,000, provided that you remove the prior data and there's no gap. If you remove the indexer and its data between the runs, the trigger should not fire.

I hope this helps!

[ra0x3]

@lostman

• Hm that's a good/interesting point thanks
• The only issue with that is, it prevents us from testing the --replace-indexer bit no?
  • Meaning if I have to shutdown/restart the indexer to index a different chunk of blocks, I wouldn't actually be testing the --replace-indexer bit on a live service with previously indexed data
  • At best I'd be testing on a fresh DB (is my thought at least)
• The main point of this issue is that the functionality works fine, it's just that I'm now seeing we don't always want this functionality (but it's fine to have by default, so long as I can opt-out of it)

[lostman]

@ra0x3, replacing the indexer is not an issue because the new indexer resumes where the replaced indexer left off. So there is no gap. However, a user could change the start block in the manifest to be farther than the currently indexed blocks and then attempt to replace the indexer, which would fail. In such a case the user would need to remove the old indexer and then deploy the new one (and I think that's correct since it would be odd for an indexer with some start block X to have indexed blocks before X).

In any case, I'm working on adding this feature.