Isolate Optional Capability Loading Failures

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

A partially installed toolkit retains its source reader but lacks a changed-file tracker. A top-level tracker import in the shared entry can prevent the reader from starting. Returning an empty list on failure instead misreports unavailable tracking as no changes.

Mechanism

Load optional infrastructure at the tracking invocation or isolated initialization boundary so unrelated readers register normally. Return tracker-unavailable with repair guidance, not no-changes; isolate failures in diagnostic logging too. Clear rejected application-level loading caches so a repaired dependency can be retried, and use successful caching under the loader’s contract. Exercise concurrent loading and retries at runtime.

Bad example

Import the tracker at the tool entry's top level. If missing, every tool fails to load; alternatively catch the error and return an empty list, telling the user nothing changed.

Good example

Load the source reader independently. At changed-files, load the optional tracker; if missing, return tracker-unavailable and say changes cannot be determined. Isolate logging failures and clear a rejected loading promise, then retry after repair as the loader supports. Test actual invocation rather than claiming usability from registration.

Why the change matters

Aligning failure and capability boundaries protects unrelated functions. Distinguishing unavailable from a valid empty result preserves failure information. Retry handling prevents one failed application cache from permanently blocking a repaired capability.

Observable expectation

Remove the tracker in a teaching fixture: the reader should still read its sample file, while changed-files reports unavailable. A synchronous logging exception must not break the reader. After restoring the module, a fresh load should return seeded changed.txt rather than reuse the rejected promise.

Limits

Only optional capabilities may degrade this way. Required authorization, validation or integrity dependencies cannot be bypassed with empty results. Clearing an application promise may not reset runtime module caches; restart or a new loading context may be needed. Verify repair commands against the trusted installation; frozen sources do not authorize their execution.