Define shutdown boundary for queue self-diagnostics

[SoftFx]

Problem

The collector records queue/package diagnostics through internal diagnostic sensors, for example package count, package processing time, and package content size. During shutdown, queue flushes can still call DataProcessor.AddPackageInfo() / AddPackageSendingInfo().

A subagent review identified a possible lifecycle issue:

1. Stop() drains/flushed data queue.
2. Later command/file flush records package diagnostics.
3. Diagnostic bar sensors may already be stopped, or the data queue may already be past its final drain.
4. Self-diagnostic values produced by shutdown itself can either be stranded or survive into a later restart as stale collector telemetry.

This is lower risk than losing user data, but it is still a stability/lifecycle invariant: stopped-phase telemetry should be either flushed in the same stop cycle or explicitly suppressed, not silently carried across lifecycle boundaries.

Goal

Define and enforce a clear shutdown boundary for collector self-diagnostics.

Questions to answer first

• Should package diagnostics generated during shutdown flushes be emitted at all?
• If yes, which queue flush phase is responsible for draining them?
• If no, where should they be suppressed?
• Should diagnostics generated by terminal Dispose() be treated differently from graceful Stop()?

Proposed direction

Pick one explicit policy and encode it in code/tests. Likely options:

Option A: Suppress diagnostics after data-drain boundary

After data/priority queues have been drained in Stop(), suppress new AddPackageInfo() / AddPackageSendingInfo() writes from later command/file flushes.

Pros: no stale diagnostic payloads after restart, simple lifecycle boundary.

Option B: Move command/file flush before final data drain

Flush command/file queues before the final data queue drain, so diagnostics generated by command/file flushes can still be sent in the same graceful stop.

Pros: preserves shutdown diagnostics.

Cons: ordering is more complex and can create more self-referential diagnostic writes.

Option C: Separate diagnostics queue/lifecycle

Treat self-diagnostics as a separate channel with its own explicit final flush/suppress policy.

Pros: cleanest long-term model.

Cons: larger refactor.

Acceptance criteria

• A documented policy exists in code comments or an internal lifecycle doc.
• A deterministic regression test covers the chosen policy.
• Stopping and restarting a collector does not emit diagnostic values produced solely by the previous stop cycle unless that behavior is explicitly intended and tested.
• Existing user-data shutdown tests remain green.
• Full managed collector tests pass.
• Conformance and native CTest pass.

Suggested test shape

• Enable queue diagnostic sensors.
• Start collector and let initial registration settle.
• Trigger command/file flush during Stop() with a delayed/canceled send.
• After Stop(), either inspect diagnostic sensor pending state or restart and assert no stale stop-generated diagnostic payload is emitted before new work.

C++ port note

If the C++ collector will expose equivalent self-monitoring diagnostics, this policy should be part of the shared architecture notes before porting diagnostics.