Skip to content

Stale-container recorder: engine checks, always-on sampling, findings that survive the log - #279

Open
Krathe82 wants to merge 4 commits into
DanderBot:mainfrom
Krathe82:krathe/stale-recorder-v2
Open

Krathe82 wants to merge 4 commits into
DanderBot:mainfrom
Krathe82:krathe/stale-recorder-v2

Conversation

@Krathe82

@Krathe82 Krathe82 commented Oct 2, 2026

Copy link
Copy Markdown
Contributor

Summary

Diagnostics only, no behaviour change for users. Three commits make the stale-container recorder (Debug/AuraUnitScan.lua) catch what it was missing, and keep its findings in the log:

  1. AD slots: log every owner retarget. The aura rows logged their retargets and the placed indicators never did. The WRONG-AD-SLOTS row now also carries the preconditions the Factory's retarget walk needs, so a field log names the gate it fell at.

  2. Ask the engine, sample always, log start and end. The recorder now samples out of combat as well (1s in combat, 2s idle), keys saved rows by session with the latest detail, and adds two checks that ask the engine instead of DF's bookkeeping:

    • ENGINE-UNIT: the container's own GetUnit differs from the frame's unit;
    • SHOWN-DISABLED: the window is shown but the container is disabled, so it isn't listening for UNIT_AURA.

    Findings go to a new UNITSCAN debug category as a START line and a CLEAR line with duration. This is what caught the roster-renumbering bug fixed in its own PR.

  3. Keep findings from being evicted. The range-crossing aura snapshot moves to the RANGE channel (noisy, off by default). It was ~78% of a raid evening's log, and the log evicts oldest INFO first. Recorder lines are now WARN, and each session leaves a heartbeat row in DandersFramesDebugDB.unitscanRuns, so "nothing caught" can be told apart from "never ran". The file header also records why a shown-but-stale icon can't be detected: the engine secret-wraps button visibility and icon, out of combat too.

How to test

Enable the debug console, play a session, /reload. /run DandersFrames:DumpAuraUnitLog() prints the session heartbeat and any findings, and UNITSCAN START/CLEAR lines sit in the log timeline.

…d none pending

Krathe, 2026-09-21 raid: a burst of Aura Designer indicators going stale --
zero duration, stuck on frames -- that recovered on their own. The passive
recorder had the shape: seventeen frames whose slot owner sat on the PREVIOUS
occupant's raid token with no retarget pending, nine of them in one wave when
the roster shifted by one mid-pull (19:28:43-56), two for three minutes across
an out-of-combat window, three for four minutes. A frame on raid16 rendering
raid17's auras is exactly an indicator whose duration reads zero and does not
clear.

What the log could not say is whether SetSlotOwnerUnit was ever reached for
those frames. The aura rows log their retargets; the placed indicators never
did. Now they do, one line per owner retarget, marked when combat defers it.

The recorder's WRONG-AD-SLOTS row carries the walk's preconditions with it:
how many placed entries the frame's store holds, how many of their handles
belong to this owner, how many are parked, whether AD and the factory are on
for the frame, whether it is visible, whether the unit exists, and when
SyncFrame last ran on it (stamped at its entry). The next raid names the gate
the walk fell at instead of only that it fell.

Diagnostic only; no behaviour change.
…t and end

Krathe, 2026-09-24, after an Aura Designer aura went stale briefly and the
recorder had nothing: "the log should find the problem -- it's pointless if it
keeps missing it."

It missed for three reasons, all fixed here:

1. It sampled only in combat. It now samples all the time -- every second in
   combat, every two seconds out of it.

2. Saved rows were merged by key with no date, and the detail was written once
   and never refreshed. A repeat in a later session looked like the old row
   with a bigger count, and new diagnostic fields never appeared on a key that
   already existed. Rows now carry their session, and the detail is always the
   latest.

3. Every check trusted DF's own bookkeeping. Two new checks ask the engine:
   ENGINE-UNIT (the container's own GetUnit differs from the frame's unit, so
   it is parsing someone else's auras) and SHOWN-DISABLED (the window is shown
   but the container is disabled, so it is not listening for UNIT_AURA). They
   cover every lane: aura rows, dispel, the dispel icon row, every Aura Designer
   container store, and the AD slot owner.

Every finding now goes into the debug log as well, under a new UNITSCAN
category: one START line when a problem appears and one CLEAR line with its
duration when it goes away. That is the timeline, next to the roster, latch
and retarget lines, so a reload is the whole report.

Hidden frames are skipped (a frame nobody can see cannot show a stale aura;
the old version filled the log with frames whose unit had left). Test mode is
skipped. Whether a container is still registered for UNIT_AURA cannot be
checked: IsEventRegistered is refused on containers by the EventRegistrations
forbidden aspect, as proven in game; SHOWN-DISABLED is the readable half.

A mock harness caught one bug before this shipped: `okE and en or nil` turns
a disabled container's false into nil, so SHOWN-DISABLED could never fire.
Explicit ifs now.

The panic snapshot (MarkAuraFault) records the engine binding and enabled
state per lane too.
…icted

The range-crossing aura snapshot moves to the RANGE channel (noisy, off by
default). It fired on every crossing of every unit and filled ~78% of a
raid evening's log, and the log evicts oldest INFO first.

The recorder's start, clear and snapshot lines are now WARN so they outlive
the INFO chatter, and each session leaves a heartbeat row in
DandersFramesDebugDB.unitscanRuns (armed, samples, last sample, findings),
so an empty findings list can be told apart from a recorder that never ran.

Also records why a shown-but-stale aura icon cannot be detected: the engine
secret-wraps button visibility and icon, out of combat too.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant