Weather Data Lifecycle Management

Weather Data Lifecycle Management governs how long downloaded and derived weather data should be kept, by making ownership explicit for every file and directory: one-shot jobs clean promptly, interactive views retain their inputs until closed, and shared caches are never deleted as part of ordinary request cleanup. It governs lifetime and ownership only - it does not choose a data provider, decode scientific data, or define a cache eviction policy itself.

It classifies every path into one of five owner/lifetime pairs: a request workspace belongs to one operation and is deleted when that operation finishes or fails after durable outputs are saved; interactive-session data belongs to the viewer or session and is deleted when the final consumer closes or display creation fails; a shared cache belongs to a cache manager and is deleted only per its own explicit eviction policy; a user export belongs to the user and is never deleted as automatic request cleanup; and a partial file belongs to its active writer and is deleted on failure, cancellation, or successful atomic promotion. If ownership can't be stated for a path, the rule is simple: don't delete it until ownership is resolved.

from pathlib import Path
from tempfile import TemporaryDirectory


def render_once(destination):
    destination = Path(destination)
    destination.parent.mkdir(parents=True, exist_ok=True)

    with TemporaryDirectory(prefix="weather-job-") as workspace:
        workspace = Path(workspace)
        source = fetch_into(workspace)
        temporary_output = render(source, workspace / "result.png")
        temporary_output.replace(destination)

    return destination

For a one-shot workflow, all transient downloads and intermediates stay inside a request-specific temporary directory, and only the requested artifact is copied or atomically moved to its durable destination outside that directory. For an interactive workflow, where the consumer outlives the worker that created its data, ownership transfers only after the viewer or session is successfully created: the worker cleans up immediately if acquisition or display creation fails, but once display succeeds, cleanup is attached as one idempotent callback to the real consumer's close/destroy event - never to a temporary dialog, local variable, or signal that could fire before the consumer actually finishes - and if multiple consumers share the data, it's released only after the final lease closes.

Failure and cancellation handling keeps incomplete downloads under a distinct suffix so they can't be mistaken for valid data, closes file handles and memory maps before removing their paths, makes cleanup idempotent since a cancellation signal and a close event can race, and reports the exact owned path on cleanup failure rather than deleting broader parent directories. For shared caches, a request may read or populate the cache but never owns its root: validated entries are promoted atomically, a partial file is never exposed as a cache hit, and eviction goes through cache identity and metadata rather than age or filename guesswork inside request code. On the safety side, it warns against ever deleting a home directory, workspace root, cache root, or user-selected directory as a computed fallback, against globs or unresolved environment variables in destructive cleanup, and against following untrusted symlinks outside the owned workspace.

Use it when a completed render leaves large temporary files behind, an interactive view breaks because its backing data was deleted too early, cancellation or exceptions leak partial downloads, request-owned files and a shared cache are mixed together, or a background worker needs to hand off data ownership to a UI or later processing stage.

It is scoped to lifetime and ownership specifically - it does not select a data provider, decode weather data formats, or design a cache eviction algorithm; those are separate concerns it explicitly defers.

Input is a set of file/directory paths created during a weather-data workflow (downloads, derived renders, cache entries, user exports) and their consumers (one-shot job, interactive viewer, shared cache). Output is an explicit owner and deletion trigger assigned to every path, a cleanup mechanism (finally-block for request-owned data, close-event callback for interactive data) that is idempotent and safe under cancellation races, and a verification checklist covering success, failure, cancellation, and close-event paths.

Developers building weather-data pipelines or interactive weather-visualization tools who need to prevent both classes of lifecycle bug - temp files that never get cleaned up, and backing data that gets deleted out from under a still-open viewer or a still-leased shared cache entry.