Trim `history.jsonl` when `history.max_bytes` is set

[terror]

This PR honors the history.max_bytes configuration parameter by trimming history.jsonl whenever it grows past the configured limit. While appending new entries we retain the newest record, drop the oldest lines to stay within the byte budget, and serialize the compacted file back to disk under the same lock to keep writers safe.

[github-actions[bot]]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[terror]

I have read the CLA Document and I hereby sign the CLA

[etraut-openai]

@codex review

[chatgpt-codex-connector[bot]]

Codex Review: Didn't find any major issues. Bravo.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[etraut-openai]

Thanks for the contributions. It looks like the newly-added tests are failing in CI. Could you take a look?

[terror]

Thanks for the contributions. It looks like the newly-added tests are failing in CI. Could you take a look?

I believe this was because we were missing a write(true) for truncation rights on Windows. My latest commit should fix this up.

[terror]

Thanks for the contributions. It looks like the newly-added tests are failing in CI. Could you take a look?

I believe this was because we were missing a write(true) for truncation rights on Windows. My latest commit should fix this up.

Alright, so apparently on Windows adding append(true) strips the handle of FILE_WRITE_DATA, leaving only FILE_APPEND_DATA. I've gated the append(true) for unix only.

[bolinfest]

@terror thanks for taking this on!

One concern I have is that perhaps we need two limits: a soft cap and a hard cap?

Specifically, it seems like once we hit the limit, if we only delete the minimum number of lines to get under the limit, we will probably hit the limit again after another command or two, right?

Whereas if we had a "soft cap" and a "hard cap," I would say when we hit the hard cap, we reduce the file to the soft cap so we do less I/O overall, though admittedly at the cost of evicting old entries sooner than in your proposed implementation.

What do you think?

[etraut-openai]

@terror, I wanted to make sure you saw the response above. Interested in your thoughts.

[terror]

@terror thanks for taking this on!

One concern I have is that perhaps we need two limits: a soft cap and a hard cap?

Specifically, it seems like once we hit the limit, if we only delete the minimum number of lines to get under the limit, we will probably hit the limit again after another command or two, right?

Whereas if we had a "soft cap" and a "hard cap," I would say when we hit the hard cap, we reduce the file to the soft cap so we do less I/O overall, though admittedly at the cost of evicting old entries sooner than in your proposed implementation.

What do you think?

Yeah this makes sense, what do we think is a reasonable soft cap? 80% of max bytes?

[etraut-openai]

@terror, that sounds reasonable, but please make it configurable with a constant that can be adjusted if necessary. This PR has been open for a long time, so I'd like to get it over the finish line in the next few days if possible.

[terror]

@terror, that sounds reasonable, but please make it configurable with a constant that can be adjusted if necessary. This PR has been open for a long time, so I'd like to get it over the finish line in the next few days if possible.

Just pushed up some changes for this!

[etraut-openai]

@terror, CI is failing due to lint (cargo clippy) issues.