fix: a re-plan drops the holes it invalidated and restarts the tick they are addressed by

rebuild_locked() replaced the store, so produced() restarted at 0 while the
producer's tick_ kept counting: a hole's slot and tick addressing then described
a buffer that was gone, forget_holes_before() could not retire it, and a
backfill's amend fell outside the ring -- repairing nothing while the hole was
still marked repaired, which is the band reporting the opposite of the truth. A
re-plan generation is the signal rather than the stride/channel-count guard,
which a reconnect with an identical CONFIG leaves unchanged. slot_base_ is left
alone: it is relative mode's clock origin and must not walk backwards when the
user retypes the window.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Martino FerrariandClaude Opus 4.6 committed 2026-10-09 06:51:29 +02:00
1 parent 176ef1df9f
commit 8320988d96
4 files changed
+41

No files matched your search

+9
View File
@@ -336,6 +336,15 @@ void ScopeModel::rebuild_channels() {
}
void ScopeModel::rebuild_locked() {
// The store is replaced below, so every hole's `slot_begin`/`tick_begin`/`x_begin` describes a
// buffer that no longer exists: the new store's base is 0, so `forget_holes_before()` cannot
// retire them and they would shade a band over the wrong x until the table pushed them out.
// Dropping them is the honest answer -- the samples they reported absent are gone with the
// history. `++plan_generation_` is what tells the producer the same thing about `tick_`, whose
// relation to `produced()` is what addresses a backfill (see `Acquisition::on_data`).
holes_.clear();
++plan_generation_;
std::vector<double> dts;
dts.reserve(channels_.size());
for (const ChannelInfo& c : channels_) dts.push_back(c.dt);