[Bug]: Block applying in a spawned task synchronized incorrectly with in-memory update

[polydez]

More context in this thread: #340 (comment)

From @bobbinth:

In general, this mechanism is used to support the following process:

1. We start the database transaction and update the database. While this is going on, reads against the database are allowed as they read the previous state. So, the store can still serve all requests.
2. Once the data has been written to the database, we lock the in-memory structures for update. At this point, the store blocks on all requests.
3. We update in-memory structures. While this is going on, the store cannot serve any requests - so, it is critical to make this section as fast as possible.
4. We commit the database transaction and release the lock on in-memory structures.

Because database transaction and in-memory structures live in different places, we need this channel - but I am wondering if there is some way we can refactor the structure to make the code simpler.

According to the code, current implementation has these bugs:

1. When we lock in-memory data, we don't wait until commit is succeed and start to update in-memory. Even in a case of failed commit, in-memory data will be updated. By the way, we have a comment about this below.
2. Once we finish update in-memory data, we unlock it instantly without waiting for finishing of database update.
3. Error result of db.apply_block in tokio::spawn only logged, but not re-raised or handled.

[hackaugusto]

Is that a problem though? The implementation is just ensuring that reads to the in-memory representation are consistent with the DB. If the commit fails, then the whole server should come down, is it only being logged?

[hackaugusto]

Oh, okay. It seems there is a block store struct that also writes data to disk but from the in-memory side of things, so the existing code seems broken indeed.

[bobbinth]

Closed by #370.