Fix LogConfig ID lifecycle

[ataffanel]

Abstract

Fix repeated LogConfig creation and deletion so applications can use logging for more than one byte-sized ID cycle without stale host-side blocks capturing reused IDs. Log block IDs are now managed as acknowledgement-owned leases, keeping host and firmware lifecycle state aligned across deletion, reset, disconnect, and concurrent commands.

Closes #577.

Why

The previous implementation incremented an ID counter modulo 255 but never removed acknowledged-deleted configurations from Log.log_blocks. Once an ID wrapped, reply and log-data lookup found the stale configuration first. This made the firmware appear to run out of log blocks after repeated create/read/delete operations even though it had deleted them correctly.

The fix waits for the firmware deletion acknowledgement before releasing an ID. This is important because releasing earlier could route an in-flight reply or data packet to a newer configuration using the same opaque handle.

What changed

• Manage the full firmware-supported 0..255 ID range with a thread-safe FIFO free-ID pool.
• Release and detach a configuration only after DELETE succeeds or returns ENOENT; failed deletion retains the lease and can be retried.
• Make delete idempotent while its acknowledgement is pending.
• Drain IDs on disconnect and reset, restoring the complete pool only after reset is acknowledged.
• Serialize log lifecycle commands and validate registration after packet sends so reset, delete, disconnect, and synchronous driver callbacks cannot create stale follow-up commands.
• Allow a detached LogConfig specification to be registered again with a fresh lease.
• Resolve variables without an explicit fetch type fresh on each registration, without accumulating duplicates.
• Raise LogConfigError for invalid lifecycle transitions while keeping detached cleanup calls harmless.

Verification

• uv run python -m unittest discover ./test — 219 tests passed.
• Configured pre-commit hooks passed for both changed files and on every commit.
• Crazyflie over radio running the latest firmware:
  • 300 iterations using a newly constructed config each time passed.
  • 300 iterations re-registering one untyped config passed.
• Final independent standards and specification reviews reported clean.

[Copilot]

Pull request overview

This PR fixes the host-side LogConfig ID lifecycle so log block IDs can wrap and be reused safely without stale Log.log_blocks entries capturing replies/log data for reused IDs. It introduces an acknowledgement-owned “lease” model for log block IDs, aligning host and firmware state across delete/reset/disconnect and concurrent lifecycle commands.

Changes:

• Replace modulo ID counter behavior with a thread-safe free-ID pool covering the full 0..255 range, releasing IDs only after delete acknowledgements.
• Serialize log lifecycle commands (create/start/stop/delete/reset/disconnect) and validate registrations after packet sends to prevent stale follow-up actions.
• Add comprehensive unit tests for ID reuse, delete/reset/disconnect behavior, retries, and concurrency.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
cflib/crazyflie/log.py	Implements ID leasing, deferred release on delete ack, reset/disconnect draining, and command serialization with registration validation.
test/crazyflie/test_log.py	Adds tests covering ID wrap/reuse, idempotent delete, reset/disconnect semantics, retry behavior, and concurrent registrations.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

🟡 Changes recommended

LogConfig._create() iterates over log_blocks without holding the registration lock, which can race with concurrent registration/detach and raise runtime errors or compute inconsistent limits.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

There’s a confirmed TOC access race in add_config() and several new concurrency tests can hang the suite if an early assertion fails before unblocking worker threads.

Review details

Suppressed comments (4)

Previously missed (3) — in code that hasn't changed since the last review.

cflib/crazyflie/log.py:533

• add_config() reads self.toc outside of any lock and multiple times. Since refresh_toc() sets self.toc = None before acquiring any locks, a concurrent refresh can make this code raise an unexpected AttributeError (instead of a controlled LogConfigError/KeyError) or validate against two different TOC objects. Consider snapshotting toc = self.toc once (and rejecting None) and using that consistently for lookups during validation.
  test/crazyflie/test_log.py:280
• If create_send_started/delete_send_started is set slightly after the 1s timeout, the assertTrue(...wait...) will fail before the finally unblocks the worker thread, potentially leaving a non-daemon thread stuck in allow_*_send.wait() and hanging the test run. Consider registering cleanup (or using daemon threads) before the assertion so the event is always released even on early assertion failures.
  test/crazyflie/test_log.py:350
• If create_send_started is set slightly after the 1s timeout, the assertion can fail before the finally unblocks allow_create_send, leaving the started non-daemon thread stuck waiting and potentially hanging the test run. Register a cleanup to always release allow_create_send (and/or mark threads as daemon) before the assertion.

This issue also appears on line 395 of the same file.

test/crazyflie/test_log.py:400

• If create_send_started is set slightly after the 1s timeout, the assertion can fail before the finally unblocks allow_create_send, leaving the started non-daemon thread stuck waiting and potentially hanging the test run. Register a cleanup to always release allow_create_send (and/or mark threads as daemon) before the assertion.

        self.cf.send_packet.side_effect = send_packet
        start_thread = threading.Thread(target=config.start)
        start_thread.start()
        self.assertTrue(create_send_started.wait(1.0))
        disconnect_thread = threading.Thread(target=disconnect)
        disconnect_thread.start()

• Files reviewed: 2/2 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

There are confirmed callback-argument and pending-state handling bugs in Log._handle_settings_packet()/LogConfig._create() that can break user callbacks and leave configs stuck in an “active/pending” state after failures.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (2)

cflib/crazyflie/log.py:854

• On create-block failure, the code queues block.added_cb.call(False) (missing the LogConfig argument) and never clears block.pending. This can break callback signatures (most handlers expect (logconf, added)) and can leave the config permanently counted as “active”.

                        block.err_no = error_status
                        callbacks.append((block.added_cb, (False,)))
                        callbacks.append((block.error_cb, (block, msg)))

cflib/crazyflie/log.py:876

• On CMD_START_LOGGING error, the failure callback is queued as block.started_cb.call(self, False) where self is the Log instance, not the LogConfig. This is inconsistent with the normal callback signature used elsewhere (started_cb.call(logconf, started)) and will break user callbacks expecting a LogConfig.

                        block.err_no = error_status
                        callbacks.append((block.started_cb, (self, False)))

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

The CREATE_BLOCK acknowledgement handler can leave LogConfig.pending stuck True for already-added blocks, which can incorrectly inflate active-usage tracking and block future registrations.

Review details

Suppressed comments (1)

cflib/crazyflie/log.py:845

• In the CREATE_BLOCK ack handler, block.pending (and the added-state update) is only cleared/executed inside if not block.added:. If LogConfig.create() is (re)called while the block is already marked as added (or a duplicate CREATE ack arrives after block.added flipped), pending can remain stuck True, which then inflates _get_active_config_usage() and can block new configs.

                    if error_status == 0 or error_status == errno.EEXIST:
                        if not block.added:
                            logger.debug('Have successfully added id=%d', id)

                            pk = CRTPPacket()

• Files reviewed: 2/2 changed files
• Comments generated: 0 new
• Review effort level: Lite