statedb/table: allow multiple initialized transitions #95
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Currently, [Table.Initialized] is affected by a potential pitfall, as it can return false (i.e., not initialized) and a closed watch channel if any write transaction (e.g., to populate an initial state, or register a changes iterator) completed before the first initializer is registered. Similarly, the same can happen if a new initializer is registered after that the previous ones have already been marked as done. In turn, this can cause consumers to misbehave, e.g., entering a busy loop, or incorrectly thinking that the table is initialized, if relying on the channel only. Let's get this fixed by slightly reworking the internal handling of initialized, so that we correctly support multiple transitions for the same table between initialized and not initialized. The initializations status (and wait channel) returned by the [Table.Initialized] method is always consistent considering the snapshot referred to by the given [ReadTxn], and the presence of any initializer not marked done at that point. In other words, every table starts in initialized state (as no initializers are initially present), and [Table.Initialized] returns true (i.e., initialized) and a closed channel. Once one or more initializers are registered, subsequent calls to [Table.Initialized] invoked with a [ReadTxn] referring to that snapshot return false and a wait channel, that gets closed once all initializers (also considering ones potentially added afterwards) get marked as done. If a new initializer is registered again, [Table.Initialized] would return false and a new watch channel, closed again once all initializers are marked done, and so on. Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>
Similarly to the registration operation, let's panic if the target table is not included in the write transaction, to make the failure explicit, instead of silently skipping the operation and not marking the table as initialized. Signed-off-by: Marco Iorio <marco.iorio@isovalent.com>
|
joamaki
approved these changes
Jul 28, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, [Table.Initialized] is affected by a potential pitfall, as it can return false (i.e., not initialized) and a closed watch channel if any write transaction (e.g., to populate an initial state, or register a changes iterator) completed before the first initializer is registered. Similarly, the same can happen if a new initializer is registered after that the previous ones have already been marked as done. In turn, this can cause consumers to misbehave, e.g., entering a busy loop, or incorrectly thinking that the table is initialized, if relying on the channel only.
Let's get this fixed by slightly reworking the internal handling of initialized, so that we correctly support multiple transitions for the same table between initialized and not initialized. The initializations status (and wait channel) returned by the [Table.Initialized] method is always consistent considering the snapshot referred to by the given [ReadTxn], and the presence of any initializer not marked done at that point.
In other words, every table starts in initialized state (as no initializers are initially present), and [Table.Initialized] returns true (i.e., initialized) and a closed channel. Once one or more initializers are registered, subsequent calls to [Table.Initialized] invoked with a [ReadTxn] referring to that snapshot return false and a wait channel, that gets closed once all initializers (also considering ones potentially added afterwards) get marked as done. If a new initializer is registered again, [Table.Initialized] would return false and a new watch channel, closed again once all initializers are marked done, and so on.
Additionally, let's also panic if initializer is marked done while the target table is not included in the write transaction, to make the failure explicit, instead of silently skipping the operation and not marking the table as initialized.