Add timeout to Appwrite download and upload operations (C-13)

[Polichinel]

Context

unfao.py lines 131, 262, 272 make network calls to Appwrite (download_latest_file(), upload_data()) with no configured timeout. If the endpoint hangs, the pipeline blocks indefinitely with no error signal.

Requirements

• Add timeout parameter to all Appwrite operations (download and upload)
• If timeout is exceeded, log ERROR and raise (ADR-008 compliant)
• Timeout value should be configurable or have a sensible default (e.g., 300s)

Risk Register

C-13 (Tier 2). Production reliability concern — a hung Appwrite connection blocks the pipeline indefinitely.

Dependencies

May require changes in views-pipeline-core's DatastoreModule if it doesn't expose a timeout parameter. Investigate before implementing.

[Polichinel]

Status vs current development (2026-06-27): still valid; call sites changed; pipeline-core still has no timeout knob.
The S3 work (#54) refactored the forecast read, so the line refs are stale. Current Appwrite call sites in unfao.py:

• get_latest_file_id (:106), get_file_metadata (:111), download_prediction (:121) — forecast read
• upload_data (:319 historical, :330 forecast)

(download_latest_file no longer used.) Confirmed: pipeline-core's DatastoreModule/AppwriteConfig expose no timeout parameter (grep of modules/datastore/datastore.py + modules/appwrite/file.py = 0 hits). So the dependency note holds: this needs a pipeline-core change (or a client-side wrapper) first. Still Tier 2.

[Polichinel]

Upstream dependency filed: views-pipeline-core#248 — DatastoreModule has no network timeout at any layer (config, client, or per-call; the Appwrite SDK Client has no set_timeout), so vpp cannot bound these calls itself. This issue stays open as the vpp-side tracker, blocked on pipeline-core#248; once a timeout knob lands upstream, the vpp fix is to set it (and logger.error+raise on timeout, ADR-008).

[Polichinel]

Closed by the views-pipeline-core 3.0.0 bump (#216), not by work in this repo — and that is the right outcome for this issue.

The ask was to add timeouts to our Appwrite download/upload calls. But we do not own those calls: they go through views_pipeline_core.modules.datastore, so a timeout added here would have been a wrapper around someone else's client.

3.0.0 ships modules/appwrite/transport.py::install_request_timeout(), and modules/appwrite/file.py calls it itself during AppWriteFileModule.__init__. The SDK has a single outbound HTTP call site, so uploads, downloads and metadata searches are all bounded by one chokepoint. Verified live in an isolated venv built from PyPI: after constructing a datastore, appwrite.client.requests is a timeout-injecting wrapper with _timeout = 30.0.

Register C-13 closed with the same evidence. The three line numbers this issue cites (unfao.py:131/262/272) have all moved since it was written; the calls now route through _ContractStorePort.