Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

ops: prod still has no persistent disk, so protocol runs reset on every deploy

Open
  • Is something wrong?
#470 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
postgresql, python
Domain
backend, databases, infrastructure

Research direction

Start by reading CLAUDE.md’s “Prod deploy reality” note and the storage configuration in render.yaml; then inspect domain/runs/repository.py to understand the protocol-run state at risk. The issue needs a budget and architecture decision among attaching a disk, using a separate Postgres backend, or accepting and documenting the current behavior. Done means the chosen approach and its treatment of idempotency_keys are decided and recorded.

Written by the indexing model from the issue text.

Description

bug

Split out of #308 so it does not die with that issue. The 2026-09-11 plan upgrade fixed the RAM and nothing else — this is the half that survived.

State (Render API, 2026-09-14)

Service srv-d7lbmpjbc2fs73bcr6t0: plan: 1c-2g, disk: null.

render.yaml declares a 1GB disk at /data and sets DATABASE_PATH=/data/backtest.db, but that file is documentation — prod does not sync from it. With no disk, DATABASE_PATH falls back to the committed seed dashboard/storage/data/backtest.db, which is replaced from git on every deploy.

Impact

Every deploy destroys:

  • protocol_runs / protocol_steps (domain/runs/repository.py)
  • idempotency_keys

These three have no Postgres option. USERS_DATABASE_URL, CONTENT_DATABASE_URL and AGENT_RUNS_DATABASE_URL already moved accounts, content and run history off this file; protocol run state is what is left.

Merging to main auto-deploys (CI deploy hook, PR #95), so this fires on an ordinary merge — an in-flight external-agent run loses its step state with no error surfaced.

Why it is not already done

A Render disk is a recurring monthly cost and pins the service to a single instance (a disk cannot be shared across replicas). That is a budget and architecture call, not a code change — hence this issue rather than a PR.

Options

  • Attach the 1GB disk render.yaml already describes. Simplest; costs money; forecloses a second replica.
  • Give protocol runs their own PROTOCOL_RUNS_DATABASE_URL Postgres backend, matching the three existing *_DATABASE_URL splits. No new spend (Neon free tier), and it is the only option compatible with numInstances > 1. idempotency_keys is deliberately hot/local (see AGENT_RUNS_DATABASE_URL in CLAUDE.md) and would need a decision of its own.
  • Accept and document. Currently the de facto state, but undocumented at the point of use.

Note

Do not read the 2GB upgrade as having fixed this. CLAUDE.md's "Prod deploy reality" bullet now states the two halves separately for exactly this reason.

Refs #308.

Dominant language
Python
Stars
767
Forks
156
Avg merge
21h 57m
Merged PRs (30d)
92

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Open-Finance-Lab/AgenticTrading

All issues in Open-Finance-Lab/AgenticTrading

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.