feat: new RPC, Bank and Cloning Pipeline #578
Conversation
- needs to be cleaned up to handle all program loaders - unwrap needs to be removed as well
- covered in newer tests - not repeatable due to hardcoded accounts - testing obsolete behavior (non-eager cloning)
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
magicblock-account-cloner/src/lib.rs (1)
347-352: Critical: Add timeout to slot-advancement loop to prevent indefinite hang.This issue was flagged in a previous review and remains unresolved. The busy-wait loop has no timeout and will hang indefinitely if the validator stops advancing slots or experiences an abnormal condition. This could cause cloning operations to never complete and block the cloner thread.
Apply this diff to add a timeout:
// After cloning a program we need to wait at least one slot for it to become // usable, so we do that here let current_slot = self.accounts_db.slot(); + let deadline = tokio::time::Instant::now() + Duration::from_secs(10); while self.accounts_db.slot() == current_slot { + if tokio::time::Instant::now() > deadline { + return Err(ClonerError::CommittorServiceError( + format!("timeout waiting for slot advancement after cloning program {}", program_id) + )); + } tokio::time::sleep(Duration::from_millis(25)).await; }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
magicblock-account-cloner/src/account_cloner.rs(2 hunks)magicblock-account-cloner/src/lib.rs(1 hunks)magicblock-account-cloner/src/util.rs(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (3)
magicblock-account-cloner/src/util.rs (1)
magicblock-rpc-client/src/lib.rs (2)
get_cus_from_transaction(593-602)get_logs_from_transaction(578-582)
magicblock-account-cloner/src/account_cloner.rs (1)
magicblock-account-cloner/src/util.rs (1)
get_tx_diagnostics(7-18)
magicblock-account-cloner/src/lib.rs (6)
magicblock-chainlink/src/remote_account_provider/program_account.rs (2)
try_from(92-103)lamports(126-129)programs/magicblock/src/utils/instruction_utils.rs (4)
modify_accounts(154-160)modify_accounts_instruction(162-195)disable_executable_check_instruction(292-302)enable_executable_check_instruction(304-314)magicblock-account-cloner/src/bpf_loader_v1.rs (1)
try_from(29-74)magicblock-account-cloner/src/account_cloner.rs (1)
map_committor_request_result(24-68)magicblock-account-cloner/src/util.rs (1)
get_tx_diagnostics(7-18)magicblock-chainlink/src/cloner/mod.rs (2)
clone_account(18-22)clone_program(26-29)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: run_make_ci_test
- GitHub Check: run_make_ci_lint
- GitHub Check: run_make_ci_format
- GitHub Check: run_make_ci_test
🔇 Additional comments (11)
magicblock-account-cloner/src/util.rs (1)
7-18: LGTM: Best-effort diagnostics helper is appropriate.The function correctly implements a best-effort diagnostic extraction pattern. Swallowing errors and returning
(None, None)is appropriate here since this is used to augment error messages with additional context when available, but should not fail the primary operation if diagnostics cannot be retrieved.The double-nested
Ok(Ok(transaction))pattern correctly handles the committor's Result-wrapped Result return type.magicblock-account-cloner/src/account_cloner.rs (2)
1-22: LGTM: Error surface simplification is clean.The simplified
AccountClonerErrorenum and newAccountClonerResult<T>type alias improve API clarity. The removed variants appear to be legacy code from the previous architecture that are no longer needed with the Chainlink integration.
44-48: LGTM: Successful delegation to centralized diagnostics helper.The call to
crate::util::get_tx_diagnosticssuccessfully replaces the inline diagnostics extraction logic, eliminating code duplication as noted in past reviews. The signature extraction, committor reference, and async handling are all correct.magicblock-account-cloner/src/lib.rs (8)
48-71: LGTM: Clean struct and constructor design.The
ChainlinkClonerfields are well-organized and the constructor follows standard Rust patterns. The optionalchangeset_committorappropriately handles the case where lookup table preparation may not be configured.
73-80: LGTM: Transaction signing and scheduling is correct.As discussed in past reviews, accessing
tx.signatures[0]is safe here since all transactions are constructed locally viaInstructionUtils::modify_accountsorTransaction::new_signed_with_payer, which guarantee at least one signature.
82-101: LGTM: Regular account cloning transaction is well-structured.The
AccountModificationcorrectly captures all account fields (lamports, owner, rent_epoch, data, executable, delegated) and delegates toInstructionUtils::modify_accountsfor transaction construction.
233-261: LGTM: Async lookup table preparation with appropriate error handling.The spawned task correctly clones the committor Arc, awaits the reservation asynchronously, and logs errors without blocking the clone operation. The conditional check for
PrepareLookupTables::Alwaysensures the feature is opt-in.
263-305: LGTM: Diagnostics extraction successfully deduplicated.As noted in past reviews, this function now correctly delegates to
crate::util::get_tx_diagnostics(lines 283-285), eliminating the code duplication that previously existed. The error mapping and formatting logic is appropriate for committor service errors.
310-327: LGTM: Account cloning implementation is correct.The
clone_accountimplementation properly sequences the operations: builds transaction, conditionally prepares lookup tables for delegated accounts, sends transaction, and wraps errors with context. The delegated account check before callingmaybe_prepare_lookup_tablesis correct.
151-160: Verify whether retracted program handling properly prevents uncommittable account states.The review raises a valid concern: when retracted programs trigger early returns (lines 151-160), the function skips the normal deployment flow but still returns a signature. The search results show callers only checking the
Errcase viaif let Err(err)patterns, suggesting theOkvalue may not be validated downstream.Need to verify:
- Whether callers actually validate the returned signature (or if they assume it's always valid)
- Whether the early return for retracted programs can leave delegated accounts in a state where commitment fails silently
- Whether upstream commitment logic performs signature validation before attempting to commit
The test code treating
Signature::default()as acceptable is concerning in production contexts where invalid signatures could cause transaction failures or skip commitment workflows entirely.
166-230: No changes required—V4 deployment sequence is sound.Transactions on Solana are atomic: if a single instruction fails, the entire transaction will fail and no changes will occur. This means all five instructions in the sequence (disable check, pre-deploy mod, deploy, post-deploy mod, enable check) execute as a single all-or-nothing unit. No other transaction can write to the data the transaction works with, and the result is either complete success or complete failure with no state change recorded on the ledger.
The concern about partial state or race conditions is mitigated by Solana's runtime design: all instructions within a transaction execute in order, and the runtime runs transactions in order if they touch the same accounts. The disable/enable executable check pair operates within this single atomic transaction, protected from concurrent interference.
There was a problem hiding this comment.
A quick glance with some revealed nitpicks, you don't have to address them now, just note them somewhere. I've created an issue for chainlink optimizations, where I'll keep adding potential improvement areas.
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
magicblock-accounts-db/src/tests.rs (1)
186-202: Considerexpect()for clearer test failures.The iterator usage is correct, but line 193's
unwrap()could provide a more descriptive panic message if the test setup fails.assert_eq!( - accounts.next().unwrap().1, + accounts.next().expect("should have at least one program account").1, acc.account, "returned program account should match inserted one" );
♻️ Duplicate comments (3)
magicblock-aperture/src/requests/http/mod.rs (1)
243-257: Clarify comment to distinguish Mint vs Token Account layouts.The comment at lines 243-244 states "SPL Token Account Layout Constants," but
MINT_DECIMALS_OFFSET(line 247) refers to the Mint account layout, not the Token Account layout. This can confuse future maintainers.Suggested improvement:
-// --- SPL Token Account Layout Constants --- -// These constants define the data layout of a standard SPL Token account. +// --- SPL Token Layout Constants --- +// Offsets for both Token Account and Mint account layouts. +// Token Account offsets: const SPL_MINT_OFFSET: usize = 0; const SPL_OWNER_OFFSET: usize = 32; -const MINT_DECIMALS_OFFSET: usize = 44; const SPL_TOKEN_AMOUNT_OFFSET: usize = 64; const SPL_DELEGATE_OFFSET: usize = 76; +// Mint account offsets: +const MINT_DECIMALS_OFFSET: usize = 44;This makes it clear which constants apply to which account type.
magicblock-accounts/src/scheduled_commits_processor.rs (2)
367-377: Clarify intent type in meta construction.At line 371,
intentis aScheduledBaseIntentWrapper(frompreprocess_intentreturn), butScheduledBaseIntentMeta::newexpects&ScheduledBaseIntent(line 416). This works ifScheduledBaseIntentWrapperimplementsDeref<Target = ScheduledBaseIntent>, but the implicit dereference reduces clarity.Make the type relationship explicit:
intent_metas.insert( intent.id, - ScheduledBaseIntentMeta::new(&intent, excluded_pubkeys), + ScheduledBaseIntentMeta::new(&intent.inner, excluded_pubkeys), );This improves readability and makes the code's intent clearer without relying on implicit Deref coercion.
142-175: Handle task-level failures in undelegation processing.The current implementation uses
join_all()which returns the results from successfully joined tasks, but silently ignores tasks that panic or are cancelled (JoinError). While task panics should be rare in production, they represent programming errors worth surfacing.Consider handling the outer JoinError explicitly:
- let sub_errors = join_set - .join_all() - .await - .into_iter() - .filter_map(|(pubkey, inner_result)| { - if let Err(err) = inner_result { - Some(format!( - "Subscribing to account {} failed: {}", - pubkey, err - )) - } else { - None - } - }) - .collect::<Vec<_>>(); + let mut sub_errors = Vec::new(); + while let Some(join_result) = join_set.join_next().await { + match join_result { + Err(join_err) => sub_errors.push(format!("task panicked/cancelled: {}", join_err)), + Ok((pubkey, Err(e))) => sub_errors.push(format!("Subscribing to account {} failed: {}", pubkey, e)), + Ok((_pubkey, Ok(()))) => {} + } + }Alternatively, if you prefer
join_all(), explicitly handle the outer Result layer.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (10)
docs/rpc.md(1 hunks)magicblock-account-cloner/src/bpf_loader_v1.rs(1 hunks)magicblock-account-cloner/src/lib.rs(1 hunks)magicblock-accounts-db/src/tests.rs(6 hunks)magicblock-accounts/src/scheduled_commits_processor.rs(8 hunks)magicblock-aperture/README.md(1 hunks)magicblock-aperture/src/encoder.rs(1 hunks)magicblock-aperture/src/requests/http/get_token_account_balance.rs(1 hunks)magicblock-aperture/src/requests/http/mod.rs(1 hunks)magicblock-aperture/tests/setup.rs(1 hunks)
🧰 Additional context used
🧠 Learnings (2)
📚 Learning: 2025-10-21T14:00:54.642Z
Learnt from: bmuddha
PR: magicblock-labs/magicblock-validator#578
File: magicblock-aperture/src/requests/websocket/account_subscribe.rs:18-27
Timestamp: 2025-10-21T14:00:54.642Z
Learning: In magicblock-aperture account_subscribe handler (src/requests/websocket/account_subscribe.rs), the RpcAccountInfoConfig fields data_slice, commitment, and min_context_slot are currently ignored—only encoding is applied. This is tracked as technical debt in issue #579: https://github.com/magicblock-labs/magicblock-validator/issues/579
Applied to files:
magicblock-aperture/src/encoder.rs
📚 Learning: 2025-10-21T11:00:18.396Z
Learnt from: bmuddha
PR: magicblock-labs/magicblock-validator#578
File: magicblock-aperture/src/encoder.rs:176-187
Timestamp: 2025-10-21T11:00:18.396Z
Learning: In the magicblock validator, the current slot is always the root slot. The SlotEncoder in magicblock-aperture/src/encoder.rs correctly sets `root: slot` because there is no lag between current and root slots in this architecture.
Applied to files:
magicblock-aperture/src/encoder.rs
🧬 Code graph analysis (7)
magicblock-aperture/tests/setup.rs (7)
magicblock-core/src/link.rs (1)
link(56-82)magicblock-aperture/src/lib.rs (1)
new(20-46)magicblock-aperture/src/server/http/mod.rs (1)
new(40-55)magicblock-aperture/src/server/websocket/mod.rs (1)
new(64-81)test-kit/src/lib.rs (4)
new(80-82)default(64-66)create_account(158-160)execute_transaction(234-242)magicblock-aperture/src/state/mod.rs (1)
new(76-94)magicblock-chainlink/src/chainlink/mod.rs (1)
try_new(58-81)
magicblock-aperture/src/requests/http/get_token_account_balance.rs (4)
magicblock-aperture/src/requests/http/mod.rs (1)
read_account_with_ensure(100-115)magicblock-aperture/src/requests/mod.rs (1)
params(22-26)magicblock-aperture/src/error.rs (1)
invalid_params(78-83)magicblock-aperture/src/requests/payload.rs (3)
encode(61-79)encode(105-115)encode(120-133)
magicblock-accounts-db/src/tests.rs (3)
magicblock-accounts-db/src/lib.rs (3)
next(386-394)get_account(335-338)new(42-72)test-kit/src/lib.rs (1)
get_account(271-281)magicblock-core/src/traits.rs (1)
get_account(12-12)
magicblock-account-cloner/src/lib.rs (5)
programs/magicblock/src/utils/instruction_utils.rs (4)
modify_accounts(154-160)modify_accounts_instruction(162-195)disable_executable_check_instruction(292-302)enable_executable_check_instruction(304-314)magicblock-account-cloner/src/bpf_loader_v1.rs (1)
try_from(31-79)magicblock-account-cloner/src/account_cloner.rs (1)
map_committor_request_result(24-68)magicblock-account-cloner/src/util.rs (1)
get_tx_diagnostics(7-18)magicblock-chainlink/src/cloner/mod.rs (2)
clone_account(18-22)clone_program(26-29)
magicblock-aperture/src/encoder.rs (5)
magicblock-aperture/src/requests/payload.rs (5)
encode(61-79)encode(105-115)encode(120-133)encode_no_context(85-100)encode_no_context(138-148)magicblock-aperture/src/utils.rs (3)
from(22-26)from(93-117)new(130-140)magicblock-aperture/src/requests/params.rs (5)
from(27-29)from(33-35)from(39-41)from(45-47)from(51-53)magicblock-core/src/link/accounts.rs (1)
new(39-49)magicblock-aperture/src/state/subscriptions.rs (1)
new(330-343)
magicblock-accounts/src/scheduled_commits_processor.rs (5)
magicblock-core/src/link.rs (1)
link(56-82)magicblock-chainlink/src/chainlink/fetch_cloner.rs (2)
new(134-158)None(278-278)magicblock-aperture/tests/setup.rs (2)
new(83-138)chainlink(58-68)magicblock-account-cloner/src/lib.rs (1)
new(57-71)magicblock-aperture/src/state/mod.rs (1)
new(76-94)
magicblock-aperture/src/requests/http/mod.rs (10)
magicblock-aperture/src/requests/http/get_token_account_balance.rs (2)
size_of(56-56)get_token_account_balance(17-71)magicblock-aperture/src/server/http/dispatch.rs (1)
dispatch(81-109)magicblock-aperture/src/requests/http/get_multiple_accounts.rs (2)
pubkeys(31-39)get_multiple_accounts(13-43)magicblock-aperture/src/requests/http/get_program_accounts.rs (2)
accounts(40-47)get_program_accounts(13-55)magicblock-aperture/src/requests/http/get_token_accounts_by_delegate.rs (2)
accounts(66-72)get_token_accounts_by_delegate(16-76)magicblock-aperture/src/requests/http/get_token_accounts_by_owner.rs (2)
accounts(66-72)get_token_accounts_by_owner(16-76)magicblock-aperture/src/requests/http/get_account_info.rs (1)
get_account_info(12-40)magicblock-aperture/src/requests/http/get_balance.rs (1)
get_balance(9-24)magicblock-aperture/src/requests/http/send_transaction.rs (1)
send_transaction(14-51)magicblock-aperture/src/requests/http/simulate_transaction.rs (1)
simulate_transaction(22-92)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
- GitHub Check: run_make_ci_test
- GitHub Check: run_make_ci_lint
- GitHub Check: run_make_ci_test
- GitHub Check: run_make_ci_format
🔇 Additional comments (16)
docs/rpc.md (1)
5-7: Good follow-up on the previous comment.The unused markdown reference definition has been removed and the inline link has been properly added to line 6. This resolves the earlier concern about dangling references.
magicblock-accounts-db/src/tests.rs (2)
20-33: LGTM! API migration correctly applied.The test properly reflects the change from
Result-based toOption-based account retrieval, and the assertion logic is sound.
384-437: LGTM! Previous feedback addressed, API migration complete.The zero-lamport escrow semantics are correctly tested with appropriate assertion messages, the scoped borrow properly limits iterator lifetime (lines 416-422), and the migration from
ResulttoOption-based API is consistent throughout.magicblock-account-cloner/src/bpf_loader_v1.rs (2)
17-28: LGTM! Deploy slot parameterization is correct.The
create_loader_datafunction correctly uses thedeploy_slotparameter (addressing the previous hardcoded slot issue) and properly serializes the loader state with the program data.
30-80: LGTM! Program modification logic is sound.The
try_fromimplementation correctly:
- Derives the program_data_address via PDA
- Builds both ProgramData and Program account modifications
- Sets appropriate owners, rent epochs, and executable flags
- Uses
Rent::default()(confirmed acceptable per maintainer's prior feedback)magicblock-account-cloner/src/lib.rs (7)
56-101: LGTM! Constructor and transaction helpers are well-structured.The
ChainlinkClonerconstructor provides clean dependency injection, and the helper methods correctly build transactions from account data. Thesend_transactionmethod's signature access (line 77) is safe as confirmed in prior discussions.
103-148: LGTM! V1 program cloning logic is correct.The V1 path properly:
- Calculates a safe deploy_slot using
saturating_sub(5).max(1)to ensure it's at least 1- Creates both program data and program account modifications via
BpfUpgradableProgramModifications- Builds the transaction with the validator authority as signer
149-238: LGTM! V4 deployment sequence correctly handles executable constraints.The non-V1 loader path implements a careful deployment sequence:
- Returns
Nonefor retracted programs (preventing ER inconsistency)- Disables executable checks to allow modification
- Creates the program account with executable=true in retracted state
- Executes the deploy instruction
- Updates with post-deploy state (authority, etc.)
- Re-enables executable checks
This bracket pattern (disable → deploy → enable) is a deliberate workaround for runtime constraints and is correctly implemented.
240-268: LGTM! Lookup table preparation is appropriately asynchronous.The method correctly:
- Checks the config before spawning
- Spawns an async task to avoid blocking the clone operation
- Logs errors from the spawned task for observability
- Only triggers for delegated accounts (called from line 329)
270-312: LGTM! Error augmentation with diagnostics is well-implemented.The method properly uses the extracted
get_tx_diagnosticshelper (fromutil.rs, addressing prior duplication feedback) to enrichTableManiaErrormessages with CUs and logs. This provides valuable debugging context for transaction failures.Based on learnings
317-334: LGTM! Account cloning implementation is correct.The method:
- Builds the cloning transaction with the current blockhash
- Conditionally prepares lookup tables for delegated accounts
- Wraps errors with appropriate context (
FailedToCloneRegularAccount)
336-365: LGTM! Program cloning correctly handles deployment and retracted state.The implementation:
- Attempts to build the deployment transaction (returns
Noneif retracted)- Sends the transaction if deployment is needed
- Waits for slot advancement to ensure the program becomes usable (lines 356-359)
- Returns a sentinel signature for the retracted no-op case (line 363)
The slot-wait loop and sentinel return value were discussed in prior reviews and accepted by the maintainer as appropriate tradeoffs.
magicblock-aperture/src/requests/http/get_token_account_balance.rs (1)
17-71: LGTM! Clean two-phase SPL token balance implementation.The handler correctly:
- Fetches the token account and extracts the mint pubkey
- Fetches the mint account to obtain decimals
- Computes the UI amount with proper decimal scaling
- Handles all error paths with clear messages
The use of
read_account_with_ensureguarantees accounts are cloned from chain if needed.magicblock-aperture/src/encoder.rs (1)
21-201: LGTM! Well-structured encoder subsystem.The encoder trait and implementations provide clean abstractions for WebSocket notifications:
- Type-safe with
SlotandSubscriptionIDparameters- Each encoder handles its specific payload type with appropriate filtering
- Consistent use of
NotificationPayload::encodefor serializationThe
root: slotassignment inSlotEncoder(line 197) is correct per the architecture where current slot is always rooted.Based on learnings
magicblock-aperture/src/requests/http/mod.rs (2)
58-92: LGTM! Efficient body handling with DoS protection.The implementation correctly:
- Avoids allocation for single-chunk bodies (the common case)
- Enforces a 1 MiB size limit to prevent DoS attacks
- Handles multi-chunk transfers properly
The zero-copy optimization for single chunks is a nice touch for performance.
155-191: Well-structured transaction preparation with proper validation.The method correctly handles:
- Multiple encoding formats (Base58, Base64)
- Optional blockhash replacement for simulation scenarios
- Blockhash validity checks against the ledger
- Transaction sanitization with configurable signature verification
The interaction between
replace_blockhashandsigverifyis correctly designed: when blockhash is replaced, the caller must disable signature verification.
PR
Summary by CodeRabbit
-
- Magicblock Aperture: production-ready JSON‑RPC HTTP + WebSocket server with Solana‑compatible endpoints (account/program/token queries, blocks/slots, signatures, send/simulate transactions, airdrop) and live subscriptions.
-
- RPC docs wording clarified for WebSocket event subscriptions.
-
- Updated local Solana test validator version and improved test runner for faster, parallel feedback.
: Major Refactoring & Chainlink IntegrationNew Features
Documentation
Chores
magicblock-bank,magicblock-rpc,magicblock-pubsub,magicblock-geyser-plugin, and several other utility/testing crates have been deleted.magicblock-aperturecrate. Cloning pipeline (3 crates) has been rewritten as the newmagicblock-chainlinkcrate.test-kitcrate is added (derived from previous test-core crate). Integration tests (test-integration/) require careful review to ensure coverage of refactored and new functionality.magicblock-chainlink, lots of crates supporting the old cloning pipeline and dependency on conjunto crates were removed.End of Summary by CodeRabbit
PR Summary: Major Refactoring & Chainlink Integration
magicblock-bank,magicblock-rpc,magicblock-pubsub,magicblock-geyser-plugin, and several other utility/testing crates have been deleted.magicblock-aperturecrate. Cloning pipeline (3 crates) has been rewritten as the newmagicblock-chainlinkcrate.test-kitcrate is added (derived from previous test-core crate). Integration tests (test-integration/) require careful review to ensure coverage of refactored and new functionality.magicblock-chainlink, lots of crates supporting the old cloning pipeline and dependency on conjunto crates were removed.Review Guide
Phase 1: Review New Core Crates
magicblock-aperture:lib.rs::JsonRpcServer::run->server/->requests/->state/.magicblock-rpc,magicblock-pubsub, and parts ofmagicblock-bankis correct. Understand its interaction withmagicblock-processor(sending transactions/requests) andaccountsdb/ledger(fetching state). This crate replaces many deleted ones.magicblock-chainlink:lib.rs->chainlink/->remote_account_provider/.RemoteAccountProvider. Check error handling.Phase 2: Review Core Validator Adaptations
magicblock-core:link.rs::link.aperture) andmagicblock-processor. Ensure data structures are appropriate for the refactored architecture. The most important type isTransactionSchedulerHandlewhich is the only way to interact with execution engine (replacesexecute_*methods in the bank)magicblock-processor:lib.rs->scheduler.rs->executor/processing.rs.magicblock-bankis gone. Examine how transactions are received from sources (likeapertureviamagicblock-core::link) and executed. Verify state updates, fee logic, built-in handling, interacts with the rest of the validator viamagicblock-core::linkand shared state (accountsdb/ledger)Phase 3: Validate Refactoring & Interactions
bank,rpc,pubsub,geyser), explicitly confirm its core responsibilities are correctly handled withinmagicblock-apertureor other remaining crates.getAccountInfo) ->aperture->accountsdb.aperture->core::link->processor.aperture-> relevant state updates.chainlink->accountsdb/basechainTips
Code owner relevant code review
committor-servicecrate should be carefully reviewed by @taco-paco.Mainly the changes in these crates are related to the removal of the bank and different approach to the transaction execution.
Deprecated Tests
I decided to deprecate chainlink unit tests that call into the program directly using the solana test context with banks client underneath. I wrote those and they are also covered with integration tests now.
Without hacking the SVM crate with special exceptions while testing they won't run since we cannot ever add a delegated account to the banks client nor can we run a modification since we cannot make the validator auth privileged either (tried a bunch of stuff).
Follow Up Work
Migration to new AccountsDB
Since the account format has been modified in accountsdb, the data migration is necessary, which can be achieved with a migration tool