[gmaclennan]

When an observation's photo or audio has only partly synced to the server, fetching it through /projects/:id/attachments/... returns a 500 with the body {"error":{"code":"INTERNAL_SERVER_ERROR","message":"fetch failed"}}. Nothing in that tells the client whether the attachment is missing, broken, or just not here yet.

The attachments route in src/routes.js proxies the request to core's internal blob server with fetch(). For a blob whose first block is present but a later block is missing, core resets the socket before sending headers, so fetch() rejects and the rejection falls through to the generic error handler. This catches the rejection, logs the underlying error at warn level so the cause reaches the server logs, and returns 502 with a stable code, ATTACHMENT_UPSTREAM_UNAVAILABLE, and a message saying the attachment may not be fully synced yet. Successful responses and upstream 404s pass through as before. The new test writes a three-block blob directly on the server, clears all but block 0, and checks the response.

The route also copied every upstream header into the reply, including hop-by-hop ones like connection and transfer-encoding that describe the internal connection rather than the attachment. Those are now skipped. This part is defensive rather than a visible change: Node's HTTP server re-adds its own connection, keep-alive and transfer-encoding headers, so clients see the same headers before and after.

Related changes. digidem/comapeo-core#1350 makes the blob server answer a partial blob with a 404 and the code BLOB_NOT_AVAILABLE_ERROR before any headers are sent. Once the cloud runs a core with that change, the socket reset handled here will rarely happen and the 404 passes straight through to the connector. This change still earns its place as the safety net for any other upstream failure, and because cloud 0.4.x can ship it without a core bump.