Story: Move reporting's write path onto the storage protocol

Table of Contents

This page documents a story in Sprint 26. It captures the goal, current status, acceptance criteria, and the tasks that compose it.

1. Goal

The last consumer moves onto the bucket and key protocol, and the two consumers that already moved are verified again on the current tree.

ores.reporting gathers a report's inputs by asking ores.trading and ores.marketdata to write them to object storage, and ores.ore reads them back when it packages the report. The writer named the bucket report-data and built a two-segment key; the reader named ores and received the writer's keys. So the two disagreed about where one object lives, and the packaging step could not find its inputs.

The handlers in the middle own neither name: the bucket and the key arrive in the request. That is why the interface migration could move compute and ore and leave this one behind, and why the work is in the caller.

2. Status

Field Value
State DONE
Parent sprint Sprint 26
Now Nothing.
Waiting on Nothing.
Next Nothing.
Last touched 2026-09-27
End 2026-09-27

3. Acceptance

  • The reporting storage plan names the protocol bucket and builds both keys with object_keys::make.
  • The capture reporting-writes-a-bucket-ore-does-not-read is resolved and closed.
  • compute publishes a package and ORE round-trips a document on the current tree, on the protocol keys.

4. Tasks

Task State Start End Description
Scaffold story: Move reporting's write path onto the storage protocol DONE 2026-09-27 2026-09-27 Story scaffolding rides this task: documents, sprint wiring, and the scaffold PR. Close it before merging that PR.
Point the reporting storage plan at the bucket and key protocol DONE 2026-09-27 2026-09-27 Point the plan at the protocol bucket, build both keys with object_keys::make, and verify compute and ORE on the current tree.

5. Decisions

  • The component keeps no bucket name. report_data_bucket was deleted rather than repointed. Keeping the name would leave a second place where the bucket is spelled, which is what drifted in the first place.
  • The stale comments are part of the fix. Three of them still named the retired bucket, and one was the model the ORE import protocol generates from. A name that survives in prose is a name that comes back in code.

6. Out of scope

  • The modified_by failure the ORE import hits after the bundle is fetched, and the credit-instrument tenor check beside it. Neither is a storage-key problem, and both belong to the components that own them.
  • Granting storage::objects:* to a human or tenant-admin role. Only the service roles hold it today, so a tenant admin cannot reach the raw shell surface; the verifications run as the system admin, which holds the service roles.

7. Result

Closed on the story's one work task. The reporting write path builds the protocol's key under its own service segment, so the blob it stores is the one ores.ore fetches back, and the component no longer spells a bucket name at all.

Verified live on the current tree: compute published the ORE engine package to ores/compute/packages/ORE-1.8.17.0/… with a server-computed digest that matches both the tarball and the seeded package_uri, and ORE wrote ores/ore/imports/<id>.tar.gz and read it back, parsing 46 trades from it. Both directions of both consumers therefore move over the protocol keys.

The two captures this defect produced are resolved and moved to discarded, and no source reference to report-data or ore-imports remains.

Emacs 29.3 (Org mode 9.6.15)