Weather Data Lifecycle Management

Overview

Keep downloaded and derived weather data for exactly as long as its consumer needs it. Make ownership explicit so one-shot jobs clean promptly, interactive views retain their inputs until close, and shared caches are never deleted as request cleanup.

This skill governs lifetime and ownership. It does not choose a provider, decode scientific data, or define a cache eviction policy by itself.

When to Use This Skill

• A completed render leaves large temporary files behind.
• An interactive view fails because its backing data was deleted too early.
• Cancellation or exceptions leak partial downloads and derived files.
• Request-owned files and a shared user cache are mixed together.
• Background workers transfer ownership of data to a UI or later processing stage.

Classify Every Path

Assign each file or directory one owner and one lifetime:

If ownership cannot be stated, do not delete the path. Resolve ownership first.

One-Shot Workflow

Use a request-specific temporary directory, keep all transient downloads and intermediate products inside it, and copy or atomically move only the requested artifact to its durable destination.

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

The final artifact must live outside the temporary directory. If replacement across filesystems is not atomic, copy to a temporary file beside the final destination, verify it, then replace locally.

Interactive Workflow

An interactive consumer outlives the worker that created its data. Transfer ownership only after the viewer or session is successfully created:

1. The worker owns the request workspace during acquisition.
2. If acquisition or display creation fails, the worker cleans it immediately.
3. On successful display, attach one idempotent cleanup callback to the real consumer close or destroyed event.
4. The consumer becomes the owner; the worker must not also delete the data in its ordinary finally path.
5. If multiple consumers share the same data, release it only after the final lease closes.

Do not tie cleanup to a temporary dialog, local variable, or signal that can fire before the actual consumer is finished.

Failure and Cancellation Rules

• Keep incomplete downloads under a distinct suffix or directory so they cannot be mistaken for valid data.
• Close datasets, file handles, and memory maps before removing their paths.
• Put request-owned cleanup in finally, but exclude resources whose ownership was successfully transferred.
• Make cleanup idempotent; a cancellation signal and a close event may race.
• Preserve a durable partial-result manifest when the user can retry remaining work.
• On cleanup failure, report the exact owned path without deleting broader parent directories.

Shared Cache Boundary

• A request may read or populate a shared cache but does not own the cache root.
• Promote validated entries atomically; never expose a partial file as a hit.
• Use cache identity and eviction metadata rather than deleting files by age or filename guesswork inside request code.
• Do not place user exports inside a directory that normal cache cleanup owns.
• Test that two concurrent consumers do not remove data still leased by the other.

Verification Checklist

• Every created path has a named owner and deletion event.
• One-shot operations retain only requested durable outputs.
• Interactive data remains available until the final consumer closes.
• Display-creation failure cleans immediately.

…