Repository navigation
Add timeout to Appwrite download and upload operations (C-13) #11
Description
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.
Activity
Polichinel commentedon Jun 26, 2026
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 readupload_data(:319 historical, :330 forecast)(
download_latest_fileno longer used.) Confirmed: pipeline-core'sDatastoreModule/AppwriteConfigexpose notimeoutparameter (grep ofmodules/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 commentedon Jun 27, 2026
Upstream dependency filed: views-pipeline-core#248 —
DatastoreModulehas no network timeout at any layer (config, client, or per-call; the Appwrite SDKClienthas noset_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 (andlogger.error+raise on timeout, ADR-008).docs(accuracy): S11 #197 — living docs still described code #148 dele…
Polichinel commentedon Aug 4, 2026
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(), andmodules/appwrite/file.pycalls it itself duringAppWriteFileModule.__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.requestsis 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.