Replace repo-memory patch size limit with a rate limit over time

[JamesNK]

From #28704:

The small size was a request from the git infrastructure team to discourage catastrophic growth of git histories in repos.

Instead of 100KB change limit, what about an over time rate limit. e.g. up to 1MB of changes over an hour. Then tasks that run infrequently can use the feature to save non-trival data. And a burst of activity, which pushes the usage over 100KB, doesn't break a workflow.

[pelikhan]

repo-memory is meant for small agentic memory and has by design smallish size restriction. This is the wrong abstraction to handle large scale wiki changes. It creates a potential high pressure on the git backend infrastructure.

If you need to create large amount ephemeral of data, consider cache-memory.

Proper wiki editing support is still in flight

[JamesNK]

The data isn’t ephemeral. It’s critical to my workflow running correctly.

I think a Git branch is a good fit. It sticks around (until someone deletes it), it’s versioned so I can debug changes across runs, and I can manually modify it if needed. The only problem is that sometimes the amount of data updated in a run exceeds the patch size limit.

Even putting my case aside, I don’t think a per-workflow run patch size limit is a great safeguard. I assume it’s meant to prevent large Git histories, but it doesn’t take into account how often a workflow runs.

For example, a workflow that runs continuously and in parallel, changing 10KB per run, could generate more total changes than one that runs every couple of hours and changes 200KB per run. A rate limit over time would probably do a better job of controlling that.

I’ve changed my workflow to manually clone and push in pre- and post-steps, but it would be nice to have a built-in solution.