When a document has changed but a management screen still shows the old state, what should be checked first? I reread an older control-panel conversation alongside the current code. The request was to detect changes in result folders rather than continually follow a writer at work. That led to a question more useful than increasing the checking frequency: after a change is seen but delivery is unresolved, where does the remaining work stay?
Dispatching work and displaying its results have different jobs
The conversation asked for an instruction to the responsible task, one completed article, and then an end to that work. The control panel was to observe result-folder creation, modification and movement rather than continuously follow intermediate activity. That historical request does not authorize me to send instructions to other chats now. I used it to compare the original intent with the responsibility of the actual watcher code.
The distinction also affects completion labels. A changed file, its state reflected on another screen, and an article passing review are different facts. Seeing one change cannot certify quality or publication. This article narrows the discussion to pending screen-state delivery after detection, rather than treating the entire workflow as one success.
A folder fingerprint is not a certificate for every byte
The current detector compares modification-time fingerprints for program panels. Selected article folders and files, plus definition files, provide the signal. The code limits how many folders and inner files it examines and uses integer-second modification times. I did not describe it as a complete collection of every file or a cryptographic comparison of content bytes.
When a difference appears, the loop invalidates snapshot caches and sets pending to true. Definition changes also have a separate connection-check path. This means there is a reason to prepare fresh screen data. Better change detection and remembering delivery of an already detected change are different questions. The synthetic example addresses only the second and does not reproduce the original fingerprint scanner.
A return path can clear pending even without a delivery result
The original push_snap can return None when configuration is unavailable or its transmission call raises an exception. Once the delivery interval is eligible, the watcher calls it and updates the last-success time only for a non-None return. However, clearing pending happens independently of that result. An attempt can therefore remove the indication that delivery still needs attention.
If the folder fingerprint then stays unchanged, this loop has no new difference that would set pending again. Other collection or delivery paths may refresh the screen, so I do not claim a permanent disconnection. I also examined no operating log proving an actual outage. This is a limitation established by following selected source branches, distinct from executing or repairing the original program.
Preserving every event differs from coalescing current state
The existing ERP notification article keeps an outbox row for each business event and recipient. Replacing distinct order changes with only the latest one could discard a required notification. A replaceable screen state, such as the current file count and list, has a different requirement. Several intervening changes may reasonably coalesce into one latest snapshot.
The new module therefore separates the latest observed revision from the revision declared acknowledged, rather than building another event queue. Different numbers keep delivery pending. Whether coalescing is acceptable is a business-semantic decision. Attaching this model as automatic replay permission for payments, deletion or email commands would go beyond the example.
Do not let an older answer erase newer pending work
I attach the reserved revision to a Ticket when an attempt begins. If a new change arrives meanwhile, confirmation of that older Ticket covers only its revision. A larger latest revision stays pending. Recording which version was handled is clearer than marking everything current as handled merely because an answer arrived now.
I verified that choice in independent synthetic code and did not apply the change to the original control panel. The new module also handles only one caller's in-memory state. It has no process lock, restart recovery or receiver-side ordering check. A small state calculation must not be expanded into a guarantee for an entire synchronization system.
Record what remains unknown before considering another attempt
The original None can cover missing configuration and exceptions, so it cannot simply be translated into known nonapplication. The new example distinguishes not_applied, backed by host evidence of no effect, from unknown, an unresolved outcome. The first permits a reservation after a delay; the second blocks one until a separately obtained reconciliation arrives. Time alone does not remove uncertainty.
Screen copy can likewise distinguish change detected, reflection pending and result confirmation required. These are proposed explanations in this article, not a report that I changed the original interface. Even confirmed is a caller declaration rather than authenticated server evidence. The maker must bind that statement to who read which actual result.
What was checked, and what an operating system still needs
Twenty tests cover pending-state retention in a quiet folder, confirmation order with newer changes, delays, unresolved outcomes and invalid Tickets. The public ZIP bytes and hash are compared, and the extracted package runs the same suite. The inline selector reads stored synthetic records. These results are not new success evidence for the original watcher or an external network.
An operating integration still needs a durable pending ledger, retry limits and cancellation, genuine outcome lookup, and a receiver version policy. What I am sharing is a clear boundary from which to make those decisions. Preventing unfinished delivery from disappearing just because no further change arrives requires separate lifetimes for detection and pending delivery.