fix: use committed account size for buffer allocation to handle >10KB growth

[vikions]

Description

Fixes #878

This PR addresses the issue where CommitDiff tasks would fail when account growth exceeded Solana's 10KB reallocation limit per instruction.

Problem

Previously, the CommitDiff flow used the diff size (diff.len()) to calculate buffer allocation size. When an account grew from 5KB to 16KB (11KB growth), the diff might only be 100 bytes, causing the realloc logic to skip generating multiple realloc instructions. This led to runtime failures when the commit instruction tried to reallocate more than 10KB at once.

Solution

• Added buffer_account_size: u64 field to PreparationTask to track the actual committed account size separately from the diff data
• Updated CommitDiff case to use committed_account.account.data.len() for buffer allocation while keeping diff.len() for write instructions
• Modified init_instruction() and realloc_instructions() to use the new buffer_account_size field

This ensures that when (committed_account_datalen - base_account_datalen) > 10KB, the existing realloc splitting logic in realloc_buffer.rs correctly generates multiple realloc instructions before the commit instruction.

Changes

• magicblock-committor-service/src/tasks/mod.rs: Added buffer_account_size field to PreparationTask
• magicblock-committor-service/src/tasks/buffer_task.rs: Updated CommitDiff and Commit cases to properly set buffer size

Testing

The existing realloc infrastructure (MAX_ACCOUNT_ALLOC_PER_INSTRUCTION_SIZE = 10,240) will now correctly handle large account growth scenarios.

Summary by CodeRabbit

• Refactor
  • Improved buffer-size tracking for account initialization and reallocation during transaction commitment, ensuring correct handling when stored data grows and reducing unexpected reallocations or sizing errors.

[coderabbitai]

📝 Walkthrough

Walkthrough

The PR adds a new public field buffer_account_size: u64 to PreparationTask and populates it in BufferTask preparation paths. Initialization and realloc-related code now use buffer_account_size instead of deriving size from committed_data.len(). In the CommitDiff branch the committed account size is computed separately and passed into the preparation task so realloc guidance can reference the actual buffer size.

Assessment against linked issues

Objective	Addressed	Explanation
Detect when data growth exceeds Solana's ~10KB realloc limit and issue dedicated realloc instruction(s) before commit [#878]	❓	No explicit detection of the 10KB threshold or logic that splits/generates one or more dedicated realloc instructions prior to the commit instruction is present in the provided changes; only a new field and plumbing to track buffer size were added.

Suggested reviewers

• bmuddha
• thlorenz

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

No actionable comments were generated in the recent review. 🎉

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Fix all issues with AI agents

In `@magicblock-committor-service/src/tasks/buffer_task.rs`:
- Around line 64-70: The code unnecessarily clones `data` when building
PreparationState::Required; instead compute let buffer_account_size = data.len()
as u64 before constructing the PreparationTask and then move `data` into the
committed_data field (committed_data: data) without cloning; update the
PreparationTask construction in the PreparationState::Required branch so it uses
the precomputed buffer_account_size and the moved `data` value, keeping
commit_id and pubkey the same.

[snawaz]

@vikions... is this a complete work, or are there more changes coming? Please add some tests as well.

I converted this into draft mode as the PR does not seem complete to me.

[vikions]

@vikions... is this a complete work, or are there more changes coming? Please add some tests as well.

I converted this into draft mode as the PR does not seem complete to me.

I’ll add tests for the >10KB growth case!
or are there any other problems?