feat: replace task executor with rpc client #723
Conversation
Manual Deploy AvailableYou can trigger a manual deploy of this PR branch to testnet: Alternative: Comment
Comment updated automatically when the PR is synchronized. |
📝 WalkthroughWalkthroughThis PR rewires task-scheduler startup and runtime plumbing: TaskSchedulerService::new signature changed to accept RPC/listen config plus ledger latest block and token; transaction submission switched from a TransactionSchedulerHandle to an RpcClient; task-scheduler public APIs and errors migrated to TaskSchedulerResult; scheduler DB adds created_at/updated_at and uses INSERT OR REPLACE; many validator-config call sites now use config.rpc_url()/websocket_urls(); task-scheduler integration tests were removed; numerous unrelated docs, config, and scheduler/core executor subsystems were also modified. Assessment against linked issues
Out-of-scope changes
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (1 passed)
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. Comment |
![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
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
magicblock-api/src/magic_validator.rs (1)
287-297: RpcClient wiring correctly routes through JSON-RPC for Chainlink, but relies on non-wildcard listen addressesSwitching
TaskSchedulerService::newto useRpcClient::new(config.listen.http())correctly sends crank transactions through the node's JSON-RPC stack (and therefore through Chainlink) instead of hittingTransactionSchedulerdirectly, aligning with #722.However, the current
BindAddress::http()method does not normalize unspecified addresses. Ifconfig.listenis configured as a wildcard bind (e.g.0.0.0.0:8899or[::]:8899), the RpcClient will receive an invalid endpoint likehttp://0.0.0.0:8899, causing transaction sends to fail. The default configuration uses127.0.0.1:8899, which is safe.To make this fully robust for wildcard configurations, either add normalization to
BindAddress::http()to convert unspecified IPs to loopback, or document thatlistenmust be a reachable address (not a wildcard bind).
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
magicblock-api/src/magic_validator.rs(1 hunks)magicblock-config/src/types/network.rs(1 hunks)
🧰 Additional context used
🧠 Learnings (6)
📓 Common learnings
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: magicblock-processor/src/scheduler/locks.rs:110-122
Timestamp: 2025-11-04T10:53:50.922Z
Learning: In magicblock-processor, the TransactionScheduler runs in a single, dedicated thread and will always remain single-threaded. The `next_transaction_id()` function in scheduler/locks.rs uses `unsafe static mut` which is safe given this architectural guarantee.
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: test-kit/src/lib.rs:275-0
Timestamp: 2025-11-07T13:09:52.253Z
Learning: In test-kit, the transaction scheduler in ExecutionTestEnv is not expected to shut down during tests. Therefore, using `.unwrap()` in test helper methods like `schedule_transaction` is acceptable and will not cause issues in the test environment.
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 614
File: magicblock-task-scheduler/src/db.rs:26-0
Timestamp: 2025-11-12T09:46:27.553Z
Learning: In magicblock-task-scheduler, task parameter validation (including ensuring iterations > 0 and enforcing minimum execution intervals) is performed in the Magic program (on-chain) before ScheduleTaskRequest instances reach the scheduler service. The From<&ScheduleTaskRequest> conversion in db.rs does not need additional validation because inputs are already validated at the program level.
📚 Learning: 2025-11-12T09:46:27.553Z
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 614
File: magicblock-task-scheduler/src/db.rs:26-0
Timestamp: 2025-11-12T09:46:27.553Z
Learning: In magicblock-task-scheduler, task parameter validation (including ensuring iterations > 0 and enforcing minimum execution intervals) is performed in the Magic program (on-chain) before ScheduleTaskRequest instances reach the scheduler service. The From<&ScheduleTaskRequest> conversion in db.rs does not need additional validation because inputs are already validated at the program level.
Applied to files:
magicblock-api/src/magic_validator.rs
📚 Learning: 2025-11-04T10:53:50.922Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: magicblock-processor/src/scheduler/locks.rs:110-122
Timestamp: 2025-11-04T10:53:50.922Z
Learning: In magicblock-processor, the TransactionScheduler runs in a single, dedicated thread and will always remain single-threaded. The `next_transaction_id()` function in scheduler/locks.rs uses `unsafe static mut` which is safe given this architectural guarantee.
Applied to files:
magicblock-api/src/magic_validator.rs
📚 Learning: 2025-10-21T14:00:54.642Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 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-api/src/magic_validator.rs
📚 Learning: 2025-11-20T17:25:23.444Z
Learnt from: JMirval
Repo: magicblock-labs/magicblock-validator PR: 656
File: programs/guinea/src/lib.rs:33-33
Timestamp: 2025-11-20T17:25:23.444Z
Learning: In the magicblock-validator codebase, task IDs (task_id) are i64 values that can be negative. The task scheduler is designed to handle any i64 value including negative task IDs. Task IDs are randomly generated using rand::random() which produces values across the full i64 range. No validation is needed to restrict task IDs to positive values.
Applied to files:
magicblock-api/src/magic_validator.rs
📚 Learning: 2025-11-13T09:38:43.804Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: magicblock-processor/src/scheduler/locks.rs:64-102
Timestamp: 2025-11-13T09:38:43.804Z
Learning: In magicblock-processor's TransactionScheduler (scheduler/mod.rs line 59), the executor count is clamped to MAX_SVM_EXECUTORS (63) at initialization time, and executor IDs are assigned sequentially from 0 to count-1. This architectural guarantee ensures that executor IDs used in the bitmask-based AccountLock (scheduler/locks.rs) will always be within valid bounds for bit shifting operations, making runtime bounds checks unnecessary.
Applied to files:
magicblock-api/src/magic_validator.rs
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
.gitignore(1 hunks)test-integration/programs/schedulecommit/src/api.rs(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: test-kit/src/lib.rs:275-0
Timestamp: 2025-11-07T13:09:52.253Z
Learning: In test-kit, the transaction scheduler in ExecutionTestEnv is not expected to shut down during tests. Therefore, using `.unwrap()` in test helper methods like `schedule_transaction` is acceptable and will not cause issues in the test environment.
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: magicblock-processor/src/scheduler/locks.rs:110-122
Timestamp: 2025-11-04T10:53:50.922Z
Learning: In magicblock-processor, the TransactionScheduler runs in a single, dedicated thread and will always remain single-threaded. The `next_transaction_id()` function in scheduler/locks.rs uses `unsafe static mut` which is safe given this architectural guarantee.
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 614
File: magicblock-task-scheduler/src/db.rs:26-0
Timestamp: 2025-11-12T09:46:27.553Z
Learning: In magicblock-task-scheduler, task parameter validation (including ensuring iterations > 0 and enforcing minimum execution intervals) is performed in the Magic program (on-chain) before ScheduleTaskRequest instances reach the scheduler service. The From<&ScheduleTaskRequest> conversion in db.rs does not need additional validation because inputs are already validated at the program level.
🔇 Additional comments (1)
.gitignore (1)
22-22: Appropriate addition to.gitignorefor test artifacts.The new entry
magicblock-test-storage/correctly ignores test-generated storage artifacts and aligns with the removal of the task-scheduler integration test suite. The placement within the Ledger section is consistent with related test ledger ignores.
bmuddha
left a comment
bmuddha
left a comment
There was a problem hiding this comment.
Not sure I understand where the actual requests are taking place 🤔
magicblock-task-scheduler/Cargo.toml
Outdated
| solana-sdk = { workspace = true } | ||
| solana-svm = { workspace = true } | ||
| solana-timings = { workspace = true } |
There was a problem hiding this comment.
But why those dependencies are needed here? Also please use specific solana subcrates instead of sdk, unless you have to import too many of them.
There was a problem hiding this comment.
Addressed in c231e0b, not sure where that was coming from...
There was a problem hiding this comment.
Actionable comments posted: 3
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
magicblock-account-cloner/src/lib.rs (1)
106-149: Hotfix fully disables frequency-based commits; consider making this explicitThe guard
Some(commit_frequency_ms) if commit_frequency_ms > 0 && falsemakes the scheduling branch unreachable, socommit_frequency_msis effectively ignored and onlymodify_ixis ever sent. That matches the “do not schedule frequency commits” hotfix comment but is quite implicit.Consider either:
- Gating the scheduling branch behind a clearly named constant/config flag (e.g.
ENABLE_FREQUENCY_COMMITS: bool) instead of&& false, and/or- Emitting at least a debug/warn log when
commit_frequency_msisSome(>0)to make it obvious that periodic commits are currently disabled.This keeps the hotfix behavior while making it more self-documenting and easier to flip later.
magicblock-chainlink/src/submux/subscription_task.rs (1)
14-90: SubscribeProgram handling mirrors Subscribe; consider adding targeted testsThe new
SubscribeProgram(Pubkey, usize)variant is wired consistently:
op_name,required_confirmations, and the zero-confirmations validation treat it identically toSubscribe.- Dispatch correctly calls
client.subscribe_program(program_id).await.Functionally this looks sound. To guard regressions, it would be useful to add a couple of small unit tests (similar to the existing Subscribe tests) that exercise:
- A successful
SubscribeProgramacross one or more clients, and- The zero-confirmations error path for
SubscribeProgram.That would ensure the new variant stays behaviorally aligned with
Subscribeas the API evolves.magicblock-task-scheduler/src/service.rs (1)
194-223: Note: Transaction execution result is not verified.The TODO comment at lines 197-201 correctly identifies that the transaction outcome isn't verified after
send_transaction. Since the PR objective is to ensure accounts get cloned via Chainlink, consider whether transaction failures should be handled more proactively (e.g., by polling for confirmation or usingsend_and_confirm_transaction).Would you like me to suggest an implementation using
send_and_confirm_transactionor a separate confirmation polling task?
♻️ Duplicate comments (1)
magicblock-api/src/magic_validator.rs (1)
287-297: Consider encapsulatingRpcClientconstruction insideTaskSchedulerService.Creating
RpcClient::new(config.listen.http())here exposes internal details ofTaskSchedulerService. Consider passing&config.listen(orconfig.listen.http()) to the service and letting it construct theRpcClientinternally.let task_scheduler = TaskSchedulerService::new( &task_scheduler_db_path, &config.task_scheduler, - RpcClient::new(config.listen.http()), + config.listen.http(), dispatch .tasks_service .take()This would require updating
TaskSchedulerService::newsignature to accept the URL and construct the client internally.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (3)
Cargo.lockis excluded by!**/*.locktest-integration/Cargo.lockis excluded by!**/*.locktest-integration/programs/noop/noop.sois excluded by!**/*.so
📒 Files selected for processing (39)
.github/actions/setup-build-env/action.yml(1 hunks)Cargo.toml(1 hunks)config.example.toml(1 hunks)magicblock-account-cloner/src/lib.rs(1 hunks)magicblock-aperture/src/tests.rs(2 hunks)magicblock-aperture/tests/setup.rs(2 hunks)magicblock-api/src/magic_validator.rs(3 hunks)magicblock-chainlink/src/chainlink/config.rs(2 hunks)magicblock-chainlink/src/chainlink/mod.rs(7 hunks)magicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rs(17 hunks)magicblock-chainlink/src/remote_account_provider/chain_pubsub_client.rs(6 hunks)magicblock-chainlink/src/remote_account_provider/config.rs(5 hunks)magicblock-chainlink/src/remote_account_provider/mod.rs(1 hunks)magicblock-chainlink/src/submux/mod.rs(10 hunks)magicblock-chainlink/src/submux/subscription_task.rs(5 hunks)magicblock-chainlink/tests/utils/test_context.rs(2 hunks)magicblock-committor-service/src/intent_executor/task_info_fetcher.rs(1 hunks)magicblock-config/src/config/chain.rs(2 hunks)magicblock-ledger/Cargo.toml(1 hunks)magicblock-magic-program-api/src/instruction.rs(1 hunks)magicblock-processor/src/executor/mod.rs(1 hunks)magicblock-processor/src/scheduler.rs(1 hunks)magicblock-task-scheduler/src/service.rs(9 hunks)programs/magicblock/src/magicblock_processor.rs(1 hunks)programs/magicblock/src/schedule_task/process_schedule_task.rs(1 hunks)programs/magicblock/src/test_utils/mod.rs(0 hunks)programs/magicblock/src/utils/instruction_utils.rs(1 hunks)test-integration/configs/schedule-task.devnet.toml(0 hunks)test-integration/test-chainlink/src/ixtest_context.rs(2 hunks)test-integration/test-chainlink/src/test_context.rs(2 hunks)test-integration/test-task-scheduler/src/lib.rs(1 hunks)test-integration/test-task-scheduler/tests/test_cancel_ongoing_task.rs(2 hunks)test-integration/test-task-scheduler/tests/test_reschedule_task.rs(2 hunks)test-integration/test-task-scheduler/tests/test_schedule_error.rs(2 hunks)test-integration/test-task-scheduler/tests/test_schedule_task.rs(2 hunks)test-integration/test-task-scheduler/tests/test_schedule_task_signed.rs(2 hunks)test-integration/test-task-scheduler/tests/test_scheduled_commits.rs(2 hunks)test-integration/test-task-scheduler/tests/test_unauthorized_reschedule.rs(2 hunks)test-kit/src/lib.rs(0 hunks)
💤 Files with no reviewable changes (3)
- programs/magicblock/src/test_utils/mod.rs
- test-integration/configs/schedule-task.devnet.toml
- test-kit/src/lib.rs
🧰 Additional context used
🧠 Learnings (21)
📓 Common learnings
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 614
File: magicblock-task-scheduler/src/db.rs:26-0
Timestamp: 2025-11-12T09:46:27.553Z
Learning: In magicblock-task-scheduler, task parameter validation (including ensuring iterations > 0 and enforcing minimum execution intervals) is performed in the Magic program (on-chain) before ScheduleTaskRequest instances reach the scheduler service. The From<&ScheduleTaskRequest> conversion in db.rs does not need additional validation because inputs are already validated at the program level.
📚 Learning: 2025-12-03T09:36:01.527Z
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 639
File: magicblock-chainlink/src/remote_account_provider/mod.rs:1350-1353
Timestamp: 2025-12-03T09:36:01.527Z
Learning: Repo: magicblock-labs/magicblock-validator
File: magicblock-chainlink/src/remote_account_provider/mod.rs
Context: consolidate_fetched_remote_accounts
Learning: For unexpected result counts (>2), the project prefers logging an error and returning an empty Vec over panicking; acceptable during development per maintainer (Dodecahedr0x).
Applied to files:
magicblock-chainlink/src/chainlink/config.rsmagicblock-committor-service/src/intent_executor/task_info_fetcher.rsmagicblock-chainlink/src/remote_account_provider/mod.rstest-integration/test-task-scheduler/tests/test_unauthorized_reschedule.rsmagicblock-aperture/src/tests.rsmagicblock-api/src/magic_validator.rsmagicblock-chainlink/src/submux/subscription_task.rstest-integration/test-task-scheduler/tests/test_schedule_error.rsmagicblock-config/src/config/chain.rsmagicblock-chainlink/tests/utils/test_context.rsmagicblock-chainlink/src/remote_account_provider/chain_pubsub_client.rstest-integration/test-task-scheduler/tests/test_cancel_ongoing_task.rstest-integration/test-task-scheduler/tests/test_schedule_task_signed.rsmagicblock-aperture/tests/setup.rstest-integration/test-chainlink/src/test_context.rsmagicblock-chainlink/src/chainlink/mod.rstest-integration/test-chainlink/src/ixtest_context.rsmagicblock-chainlink/src/submux/mod.rsmagicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rsmagicblock-chainlink/src/remote_account_provider/config.rs
📚 Learning: 2025-11-19T09:34:37.917Z
Learnt from: thlorenz
Repo: magicblock-labs/magicblock-validator PR: 621
File: test-integration/test-chainlink/tests/ix_remote_account_provider.rs:62-63
Timestamp: 2025-11-19T09:34:37.917Z
Learning: In test-integration/test-chainlink/tests/ix_remote_account_provider.rs and similar test files, the `_fwd_rx` receiver returned by `init_remote_account_provider()` is intentionally kept alive (but unused) to prevent "receiver dropped" errors on the sender side. The pattern `let (remote_account_provider, _fwd_rx) = init_remote_account_provider().await;` should NOT be changed to `let (remote_account_provider, _) = ...` because dropping the receiver would cause send() operations to fail.
Applied to files:
magicblock-chainlink/src/chainlink/config.rsmagicblock-chainlink/src/remote_account_provider/mod.rstest-integration/test-task-scheduler/tests/test_unauthorized_reschedule.rstest-integration/test-task-scheduler/tests/test_reschedule_task.rstest-integration/test-task-scheduler/src/lib.rsmagicblock-chainlink/src/submux/subscription_task.rstest-integration/test-task-scheduler/tests/test_schedule_error.rstest-integration/test-task-scheduler/tests/test_schedule_task.rsmagicblock-chainlink/src/remote_account_provider/chain_pubsub_client.rstest-integration/test-task-scheduler/tests/test_cancel_ongoing_task.rsmagicblock-aperture/tests/setup.rstest-integration/test-chainlink/src/ixtest_context.rsmagicblock-chainlink/src/submux/mod.rsmagicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rsmagicblock-chainlink/src/remote_account_provider/config.rstest-integration/test-task-scheduler/tests/test_scheduled_commits.rs
📚 Learning: 2025-11-12T09:46:27.553Z
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 614
File: magicblock-task-scheduler/src/db.rs:26-0
Timestamp: 2025-11-12T09:46:27.553Z
Learning: In magicblock-task-scheduler, task parameter validation (including ensuring iterations > 0 and enforcing minimum execution intervals) is performed in the Magic program (on-chain) before ScheduleTaskRequest instances reach the scheduler service. The From<&ScheduleTaskRequest> conversion in db.rs does not need additional validation because inputs are already validated at the program level.
Applied to files:
programs/magicblock/src/schedule_task/process_schedule_task.rsmagicblock-api/src/magic_validator.rstest-integration/test-task-scheduler/tests/test_schedule_error.rstest-integration/test-task-scheduler/tests/test_schedule_task.rstest-integration/test-task-scheduler/tests/test_cancel_ongoing_task.rsmagicblock-task-scheduler/src/service.rsmagicblock-account-cloner/src/lib.rs
📚 Learning: 2025-10-14T09:56:14.047Z
Learnt from: taco-paco
Repo: magicblock-labs/magicblock-validator PR: 564
File: test-integration/programs/flexi-counter/src/processor/call_handler.rs:122-125
Timestamp: 2025-10-14T09:56:14.047Z
Learning: The file test-integration/programs/flexi-counter/src/processor/call_handler.rs contains a test smart contract used for integration testing, not production code.
Applied to files:
programs/magicblock/src/schedule_task/process_schedule_task.rstest-integration/test-task-scheduler/tests/test_unauthorized_reschedule.rstest-integration/test-task-scheduler/tests/test_reschedule_task.rstest-integration/test-task-scheduler/src/lib.rsmagicblock-aperture/src/tests.rstest-integration/test-task-scheduler/tests/test_schedule_error.rstest-integration/test-task-scheduler/tests/test_schedule_task.rstest-integration/test-task-scheduler/tests/test_cancel_ongoing_task.rstest-integration/test-task-scheduler/tests/test_schedule_task_signed.rstest-integration/test-chainlink/src/ixtest_context.rstest-integration/test-task-scheduler/tests/test_scheduled_commits.rs
📚 Learning: 2025-12-01T16:02:05.367Z
Learnt from: thlorenz
Repo: magicblock-labs/magicblock-validator PR: 703
File: magicblock-chainlink/src/submux/mod.rs:652-654
Timestamp: 2025-12-01T16:02:05.367Z
Learning: In magicblock-chainlink/src/submux/mod.rs, the subscribe_program method intentionally adds program_id to program_subs before attempting the subscription. This ensures that even if the initial subscription fails or only partially succeeds across clients, the reconnection logic will retry the subscription. This is a deliberate design pattern for resilience in the multi-client architecture and should not be "fixed" to remove entries on failure.
Applied to files:
magicblock-chainlink/src/remote_account_provider/mod.rsmagicblock-chainlink/src/submux/subscription_task.rsmagicblock-chainlink/src/remote_account_provider/chain_pubsub_client.rsmagicblock-chainlink/src/submux/mod.rsmagicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rsmagicblock-chainlink/src/remote_account_provider/config.rs
📚 Learning: 2025-11-07T14:20:31.457Z
Learnt from: thlorenz
Repo: magicblock-labs/magicblock-validator PR: 621
File: magicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rs:457-495
Timestamp: 2025-11-07T14:20:31.457Z
Learning: In magicblock-chainlink/src/remote_account_provider/chain_pubsub_client.rs, the unsubscribe closure returned by PubSubConnection::account_subscribe(...) resolves to () (unit), not a Result. Downstream code should not attempt to inspect an unsubscribe result and can optionally wrap it in a timeout to guard against hangs.
Applied to files:
magicblock-chainlink/src/remote_account_provider/mod.rsmagicblock-chainlink/src/submux/subscription_task.rsmagicblock-chainlink/src/remote_account_provider/chain_pubsub_client.rsmagicblock-chainlink/src/submux/mod.rsmagicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rsmagicblock-chainlink/src/remote_account_provider/config.rs
📚 Learning: 2025-10-26T16:53:29.820Z
Learnt from: thlorenz
Repo: magicblock-labs/magicblock-validator PR: 587
File: magicblock-chainlink/src/remote_account_provider/mod.rs:134-0
Timestamp: 2025-10-26T16:53:29.820Z
Learning: In magicblock-chainlink/src/remote_account_provider/mod.rs, the `Endpoint::separate_pubsub_url_and_api_key()` method uses `split_once("?api-key=")` because the api-key parameter is always the only query parameter right after `?`. No additional query parameter parsing is needed for this use case.
Applied to files:
magicblock-chainlink/src/remote_account_provider/mod.rsmagicblock-chainlink/src/remote_account_provider/chain_pubsub_client.rsmagicblock-chainlink/src/remote_account_provider/config.rs
📚 Learning: 2025-10-21T14:00:54.642Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 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-chainlink/src/remote_account_provider/mod.rsmagicblock-api/src/magic_validator.rsmagicblock-chainlink/src/submux/subscription_task.rsmagicblock-config/src/config/chain.rsmagicblock-chainlink/src/remote_account_provider/chain_pubsub_client.rsmagicblock-chainlink/src/submux/mod.rsmagicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rsmagicblock-chainlink/src/remote_account_provider/config.rs
📚 Learning: 2025-11-07T13:09:52.253Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: test-kit/src/lib.rs:275-0
Timestamp: 2025-11-07T13:09:52.253Z
Learning: In test-kit, the transaction scheduler in ExecutionTestEnv is not expected to shut down during tests. Therefore, using `.unwrap()` in test helper methods like `schedule_transaction` is acceptable and will not cause issues in the test environment.
Applied to files:
test-integration/test-task-scheduler/tests/test_unauthorized_reschedule.rstest-integration/test-task-scheduler/tests/test_reschedule_task.rstest-integration/test-task-scheduler/src/lib.rstest-integration/test-task-scheduler/tests/test_schedule_error.rstest-integration/test-task-scheduler/tests/test_schedule_task.rstest-integration/test-task-scheduler/tests/test_cancel_ongoing_task.rstest-integration/test-task-scheduler/tests/test_schedule_task_signed.rsmagicblock-task-scheduler/src/service.rstest-integration/test-task-scheduler/tests/test_scheduled_commits.rs
📚 Learning: 2025-12-03T09:33:48.707Z
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 639
File: test-integration/test-committor-service/tests/test_ix_commit_local.rs:867-881
Timestamp: 2025-12-03T09:33:48.707Z
Learning: Repo: magicblock-labs/magicblock-validator PR: 639
Context: test-integration/test-committor-service/tests/test_ix_commit_local.rs (ix_commit_local)
Learning: The PhotonIndexer used for compressed account fetches (get_compressed_account) has built‑in retry logic (defaults to ~10 attempts), so tests should not add separate retry loops around compressed fetches unless there’s a specific need.
Applied to files:
test-integration/test-task-scheduler/tests/test_unauthorized_reschedule.rstest-integration/test-task-scheduler/tests/test_reschedule_task.rstest-integration/test-task-scheduler/src/lib.rstest-integration/test-task-scheduler/tests/test_schedule_error.rstest-integration/test-task-scheduler/tests/test_schedule_task.rstest-integration/test-task-scheduler/tests/test_cancel_ongoing_task.rstest-integration/test-task-scheduler/tests/test_schedule_task_signed.rsmagicblock-account-cloner/src/lib.rstest-integration/test-task-scheduler/tests/test_scheduled_commits.rs
📚 Learning: 2025-11-20T17:25:23.444Z
Learnt from: JMirval
Repo: magicblock-labs/magicblock-validator PR: 656
File: programs/guinea/src/lib.rs:33-33
Timestamp: 2025-11-20T17:25:23.444Z
Learning: In the magicblock-validator codebase, task IDs (task_id) are i64 values that can be negative. The task scheduler is designed to handle any i64 value including negative task IDs. Task IDs are randomly generated using rand::random() which produces values across the full i64 range. No validation is needed to restrict task IDs to positive values.
Applied to files:
test-integration/test-task-scheduler/tests/test_reschedule_task.rstest-integration/test-task-scheduler/src/lib.rsmagicblock-api/src/magic_validator.rstest-integration/test-task-scheduler/tests/test_schedule_error.rstest-integration/test-task-scheduler/tests/test_schedule_task.rstest-integration/test-task-scheduler/tests/test_schedule_task_signed.rsmagicblock-task-scheduler/src/service.rs
📚 Learning: 2025-11-04T10:53:50.922Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: magicblock-processor/src/scheduler/locks.rs:110-122
Timestamp: 2025-11-04T10:53:50.922Z
Learning: In magicblock-processor, the TransactionScheduler runs in a single, dedicated thread and will always remain single-threaded. The `next_transaction_id()` function in scheduler/locks.rs uses `unsafe static mut` which is safe given this architectural guarantee.
Applied to files:
magicblock-processor/src/scheduler.rsmagicblock-api/src/magic_validator.rsmagicblock-task-scheduler/src/service.rs
📚 Learning: 2025-10-21T11:00:18.396Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 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-processor/src/scheduler.rs
📚 Learning: 2025-11-13T09:38:43.804Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: magicblock-processor/src/scheduler/locks.rs:64-102
Timestamp: 2025-11-13T09:38:43.804Z
Learning: In magicblock-processor's TransactionScheduler (scheduler/mod.rs line 59), the executor count is clamped to MAX_SVM_EXECUTORS (63) at initialization time, and executor IDs are assigned sequentially from 0 to count-1. This architectural guarantee ensures that executor IDs used in the bitmask-based AccountLock (scheduler/locks.rs) will always be within valid bounds for bit shifting operations, making runtime bounds checks unnecessary.
Applied to files:
magicblock-processor/src/scheduler.rsmagicblock-task-scheduler/src/service.rs
📚 Learning: 2025-11-07T13:20:13.793Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: magicblock-processor/src/scheduler/coordinator.rs:227-238
Timestamp: 2025-11-07T13:20:13.793Z
Learning: In magicblock-processor's ExecutionCoordinator (scheduler/coordinator.rs), the `account_contention` HashMap intentionally does not call `shrink_to_fit()`. Maintaining slack capacity is beneficial for performance by avoiding frequent reallocations during high transaction throughput. As long as empty entries are removed from the map (which `clear_account_contention` does), the capacity overhead is acceptable.
Applied to files:
magicblock-processor/src/scheduler.rs
📚 Learning: 2025-10-28T13:15:42.706Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 596
File: magicblock-processor/src/scheduler.rs:1-1
Timestamp: 2025-10-28T13:15:42.706Z
Learning: In magicblock-processor, transaction indexes were always set to 0 even before the changes in PR #596. The proper transaction indexing within slots will be addressed during the planned ledger rewrite.
Applied to files:
magicblock-processor/src/scheduler.rs
📚 Learning: 2025-11-24T14:21:00.996Z
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 639
File: Cargo.toml:58-58
Timestamp: 2025-11-24T14:21:00.996Z
Learning: In the magicblock-validator codebase, magicblock-api/Cargo.toml intentionally uses borsh = "1.5.3" (instead of the workspace version 0.10.4) because it needs to deserialize types from the magic-domain-program external dependency, which requires borsh 1.5.x compatibility. This is an intentional exception for interoperability with the magic domain program.
Applied to files:
Cargo.tomlmagicblock-ledger/Cargo.tomlmagicblock-api/src/magic_validator.rs
📚 Learning: 2025-11-24T08:45:11.164Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 675
File: Cargo.toml:145-145
Timestamp: 2025-11-24T08:45:11.164Z
Learning: The reqwest dependency version 0.11 is intentionally used in the magicblock-validator project to maintain compatibility with the Solana client dependencies.
Applied to files:
Cargo.toml
📚 Learning: 2025-11-04T10:48:00.070Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: magicblock-processor/src/scheduler/mod.rs:217-219
Timestamp: 2025-11-04T10:48:00.070Z
Learning: In magicblock-validator, the codebase uses a pattern where types containing non-Send/non-Sync fields (like Rc<RefCell<...>>) are marked with unsafe impl Send when they are guaranteed to be confined to a single thread through careful API design and thread spawning patterns.
Applied to files:
magicblock-api/src/magic_validator.rs
📚 Learning: 2025-11-21T10:22:07.520Z
Learnt from: taco-paco
Repo: magicblock-labs/magicblock-validator PR: 661
File: magicblock-committor-service/src/intent_executor/single_stage_executor.rs:20-28
Timestamp: 2025-11-21T10:22:07.520Z
Learning: In magicblock-committor-service's SingleStageExecutor and TwoStageExecutor (single_stage_executor.rs and two_stage_executor.rs), the fields transaction_strategy, junk, and patched_errors are intentionally public because these executors are designed to be used independently outside of the IntentExecutor scope, and callers need access to these execution reports for cleanup and error handling.
Applied to files:
magicblock-api/src/magic_validator.rsmagicblock-task-scheduler/src/service.rs
🧬 Code graph analysis (13)
programs/magicblock/src/schedule_task/process_schedule_task.rs (2)
programs/magicblock/src/test_utils/mod.rs (1)
process_instruction(42-59)programs/magicblock/src/utils/instruction_utils.rs (1)
noop_instruction(285-291)
magicblock-chainlink/src/remote_account_provider/mod.rs (1)
magicblock-chainlink/src/remote_account_provider/config.rs (1)
program_subs(74-76)
test-integration/test-task-scheduler/tests/test_unauthorized_reschedule.rs (3)
test-integration/test-task-scheduler/src/lib.rs (1)
create_delegated_counter(75-124)test-integration/schedulecommit/client/src/schedule_commit_context.rs (1)
ephem_blockhash(282-284)test-integration/test-tools/src/integration_test_context.rs (1)
try_get_latest_blockhash_ephem(1085-1087)
test-integration/test-task-scheduler/tests/test_reschedule_task.rs (3)
test-integration/test-task-scheduler/src/lib.rs (1)
create_delegated_counter(75-124)test-integration/schedulecommit/client/src/schedule_commit_context.rs (1)
ephem_blockhash(282-284)test-integration/test-tools/src/integration_test_context.rs (1)
try_get_latest_blockhash_ephem(1085-1087)
magicblock-api/src/magic_validator.rs (3)
magicblock-task-scheduler/src/service.rs (1)
new(64-97)magicblock-chainlink/src/chainlink/config.rs (2)
new(12-17)default_with_lifecycle_mode(19-27)magicblock-api/src/domain_registry_manager.rs (1)
new(28-35)
magicblock-chainlink/src/submux/subscription_task.rs (1)
magicblock-version/src/lib.rs (1)
client(42-44)
test-integration/test-task-scheduler/tests/test_schedule_error.rs (3)
test-integration/test-task-scheduler/src/lib.rs (2)
create_delegated_counter(75-124)setup_validator(35-73)test-integration/schedulecommit/client/src/schedule_commit_context.rs (1)
ephem_blockhash(282-284)test-integration/test-tools/src/integration_test_context.rs (1)
try_get_latest_blockhash_ephem(1085-1087)
test-integration/test-task-scheduler/tests/test_schedule_task.rs (3)
test-integration/test-task-scheduler/src/lib.rs (2)
create_delegated_counter(75-124)setup_validator(35-73)test-integration/schedulecommit/client/src/schedule_commit_context.rs (1)
ephem_blockhash(282-284)test-integration/test-tools/src/integration_test_context.rs (1)
try_get_latest_blockhash_ephem(1085-1087)
magicblock-chainlink/src/remote_account_provider/chain_pubsub_client.rs (1)
magicblock-chainlink/src/submux/mod.rs (1)
subscribe_program(641-662)
test-integration/test-chainlink/src/ixtest_context.rs (4)
magicblock-api/src/magic_validator.rs (1)
config(367-374)magicblock-chainlink/src/remote_account_provider/config.rs (1)
default(80-88)magicblock-chainlink/src/remote_account_provider/mod.rs (1)
default(125-131)magicblock-config/src/config/chain.rs (1)
default(20-24)
magicblock-chainlink/src/submux/mod.rs (2)
magicblock-chainlink/src/remote_account_provider/config.rs (2)
program_subs(74-76)default(80-88)magicblock-chainlink/src/remote_account_provider/chain_pubsub_client.rs (3)
subscribe_program(154-157)subscribe_program(254-270)subscribe_program(455-469)
magicblock-task-scheduler/src/service.rs (1)
programs/magicblock/src/utils/instruction_utils.rs (1)
noop_instruction(285-291)
test-integration/test-task-scheduler/tests/test_scheduled_commits.rs (3)
test-integration/test-task-scheduler/src/lib.rs (2)
create_delegated_counter(75-124)setup_validator(35-73)test-integration/schedulecommit/client/src/schedule_commit_context.rs (1)
ephem_blockhash(282-284)test-integration/test-tools/src/integration_test_context.rs (1)
try_get_latest_blockhash_ephem(1085-1087)
🔇 Additional comments (63)
.github/actions/setup-build-env/action.yml (1)
30-37: LGTM—verify thatlibclang-devis actually required.The syntax and structure are correct: the multi-line script format,
apt-get updatebefore install, and the-yflag are all appropriate for CI. However, ensure thatlibclang-devis genuinely needed by the updated codebase. If adding it here is a response to build failures in the wider PR changes (e.g., due to new dependencies introduced by RPC client integration), that context should be documented in the PR description or commit message.magicblock-committor-service/src/intent_executor/task_info_fetcher.rs (1)
9-9: LGTM! Good cleanup of unused import.The removal of the unused
errorimport is appropriate since onlywarn!is used in this file.magicblock-processor/src/scheduler.rs (1)
143-152: LGTM! Good consolidation of cache operations under a single lock scope.The refactor correctly:
- Acquires the write lock once instead of potentially multiple times.
- Adds necessary
prune()cleanup to prevent cache corruption from duplicate entries.- Ensures atomicity between pruning and updating
latest_root_slot.The comment explaining why pruning is important is helpful for future maintainers.
test-integration/test-task-scheduler/src/lib.rs (1)
29-29: LGTM: Import cleanup aligns with removal of NOOP utilities.The import adjustments correctly reflect the removal of
NOOP_PROGRAM_IDandsend_noop_tx, keeping only the necessary items for the remaining test helpers.test-integration/test-task-scheduler/tests/test_schedule_error.rs (1)
31-32: LGTM: Cleaner blockhash retrieval.Replacing the noop transaction workaround with direct blockhash retrieval via
ctx.try_get_latest_blockhash_ephem()is more straightforward and aligns with the PR's shift to using the RPC client through Chainlink.test-integration/test-task-scheduler/tests/test_unauthorized_reschedule.rs (1)
35-36: LGTM: Consistent refactoring.The blockhash retrieval update matches the pattern applied across all test files.
test-integration/test-task-scheduler/tests/test_reschedule_task.rs (1)
30-31: LGTM: Consistent refactoring.test-integration/test-task-scheduler/tests/test_cancel_ongoing_task.rs (1)
30-31: LGTM: Consistent refactoring.test-integration/test-task-scheduler/tests/test_schedule_task.rs (1)
30-31: LGTM: Consistent refactoring.test-integration/test-task-scheduler/tests/test_schedule_task_signed.rs (1)
25-26: LGTM: Consistent refactoring.test-integration/test-task-scheduler/tests/test_scheduled_commits.rs (2)
25-26: LGTM: Consistent blockhash retrieval refactoring.
13-13: Clarify why this test is ignored.The
#[ignore]attribute was added without explanation. Is this test temporarily disabled due to the RPC client changes, or is there a known issue that needs to be addressed separately?Please clarify:
- Why is this test now ignored?
- Is this temporary or permanent?
- If temporary, is there a tracking issue?
programs/magicblock/src/magicblock_processor.rs (1)
80-80: LGTM!The Noop instruction handler correctly returns success without performing any operations, which is the expected behavior for a no-op instruction.
programs/magicblock/src/schedule_task/process_schedule_task.rs (1)
157-163: LGTM! Clean test refactoring.The migration from using an external NOOP_PROGRAM_ID to the internal Noop instruction via
InstructionUtils::noop_instruction(0)improves test self-containment and removes an external dependency.programs/magicblock/src/utils/instruction_utils.rs (1)
282-291: LGTM!The helper function correctly constructs a Noop instruction with the MagicBlock program ID and empty account metadata, following the same pattern as other instruction helpers in this module.
magicblock-ledger/Cargo.toml (1)
33-33: Rocksdb dependency correctly aligned with workspace.The switch to
{ workspace = true, default-features = false, features = ["lz4"] }properly references the newly introduced workspace rocksdb dependency and maintains feature consistency. This refactoring follows best practices for workspace dependency management.Cargo.toml (2)
195-212: Resolve RocksDB version mismatch between workspace dependency and git patch.The workspace declares
rocksdb = "0.22.0"but the patch references git revisiond4e9e16, which is part of v0.23.0 (not v0.22.0). This version mismatch will cause Cargo to apply code from a different minor version than declared, risking compatibility issues and unexpected behavior. Either update the workspace version to0.23.0or use a git revision that corresponds to the0.22.0release.⛔ Skipped due to learnings
Learnt from: Dodecahedr0x Repo: magicblock-labs/magicblock-validator PR: 639 File: Cargo.toml:58-58 Timestamp: 2025-11-24T14:21:00.996Z Learning: In the magicblock-validator codebase, magicblock-api/Cargo.toml intentionally uses borsh = "1.5.3" (instead of the workspace version 0.10.4) because it needs to deserialize types from the magic-domain-program external dependency, which requires borsh 1.5.x compatibility. This is an intentional exception for interoperability with the magic domain program.Learnt from: Dodecahedr0x Repo: magicblock-labs/magicblock-validator PR: 614 File: test-integration/programs/schedulecommit/Cargo.toml:19-20 Timestamp: 2025-11-07T18:19:48.996Z Learning: In Solana programs (crates depending on solana-program), the empty feature flags `custom-heap = []` and `custom-panic = []` are standard declarations required to avoid compiler warnings. These should not be flagged as unused features in Cargo.toml files for Solana program crates.
190-193: Remove this comment - solana-svm revision verification is not applicable to RPC client changes.The solana-svm dependency is used in
magicblock-processorfor transaction execution, not in the RPC aperture layer. RPC methods likesendTransactionandsimulateTransactioninteract with the transaction scheduler at a higher level and don't directly depend on solana-svm. Unless this PR modifies transaction processing logic inmagicblock-processor, the solana-svm revision change does not require verification for RPC client compatibility.Likely an incorrect or invalid review comment.
magicblock-processor/src/executor/mod.rs (1)
242-252: ConfirmForkGraph::relationshipargument semantics and forkless assumptionThis linear implementation looks correct under the stated assumption of a strictly forkless, monotonically increasing slot sequence: earlier slots as ancestors, later as descendants, equal as
Equal. It’s also a clear improvement over always returningUnrelated.Two things are worth explicitly double‑checking against the current Solana
ForkGraphusage:
- That
relationship(a, b)is indeed defined as “relationship of the block atarelative to the block atb”, soa < b => Ancestormatches the expected direction.- That no call sites rely on
Unrelated/Unknownbeing returned (since this implementation will never produce them), especially in any program‑cache invalidation or eviction paths.If both hold and the environment truly guarantees no forks, this implementation is good as‑is.
magicblock-aperture/tests/setup.rs (1)
20-67: ChainLinkConfig wiring in test setup looks correctUsing
ChainLinkConfig::default()and passing&ChainLinkConfigintoChainlinkImpl::try_newmatches the new config-driven API and keeps tests aligned with defaults. No issues spotted.config.example.toml (1)
182-185: Newremove-confined-accountsoption is consistent with existing config styleField name, default, and
MBV_CHAINLINK__REMOVE_CONFINED_ACCOUNTSenv var follow the established conventions in this file; no issues from the example-config perspective.magicblock-aperture/src/tests.rs (1)
11-52: ChainLinkConfig usage in aperture tests aligns with new APIImporting
ChainLinkConfigand passing a local&ChainLinkConfig::default()intoChainlinkImpl::try_newis a clean adaptation to the new signature and keeps tests using default chainlink behavior.magicblock-chainlink/src/remote_account_provider/mod.rs (1)
381-405: Program subscriptions from config are eagerly established; verify desired failure semanticsHooking
config.program_subs()intoSubMuxClientat startup and logging the list is good, and callingsubscribe_programhere respects the SubMux “remember program_subs and resubscribe on reconnect” pattern.Because of the
?, if anysubscribe_programcall fails hard (i.e., doesn’t reach the required confirmations across all clients),try_new_from_urlsreturns an error and theRemoteAccountProviderisn’t constructed. That’s a reasonable “fail-fast” choice if configured program subscriptions are mandatory, but it does mean transient issues on those subscriptions will prevent chainlink from starting.Please double-check that this strict behavior is intended; if program subscriptions are meant to be best-effort, you might instead want to log failures and proceed, relying on the reconnection logic to heal later.
Based on learnings, this keeps SubMux’s program_subs-based reconnection behavior intact.
magicblock-chainlink/src/chainlink/config.rs (1)
5-27:remove_confined_accountsfield is correctly added and defaultedAdding
pub remove_confined_accounts: booland initializing it tofalsein bothnewanddefault_with_lifecycle_modekeeps defaults consistent with the derivedDefaultand avoids surprising behavior changes unless explicitly configured.test-integration/test-chainlink/src/test_context.rs (1)
26-129: Test context’s ChainLinkConfig usage matches the new Chainlink::try_new signatureImporting
ChainLinkConfigand passing&ChainLinkConfig::default()intoChainlink::try_newcorrectly adapts the test harness to the new API while keeping behavior on defaults; the separatelifecycle_modefed intoRemoteAccountProviderConfigremains unchanged and appropriate for these tests.magicblock-chainlink/tests/utils/test_context.rs (1)
110-117: LGTM!The
Chainlink::try_newcall now correctly passes&ChainLinkConfig::default()to align with the updated constructor signature that accepts a config reference.magicblock-config/src/config/chain.rs (1)
44-58: LGTM!The addition of
serde(default)enables graceful deserialization when fields are missing from config files. The newremove_confined_accountsfield is well-documented and defaults tofalse(viaDefaultderive), which is a safe default for this feature flag.test-integration/test-chainlink/src/ixtest_context.rs (2)
26-26: LGTM!Import correctly includes both
ChainLinkConfigandLifecycleMode, both of which are used in this file.
143-150: LGTM!The
Chainlink::try_newcall correctly uses&ChainLinkConfig::default()to match the updated constructor signature.magicblock-api/src/magic_validator.rs (2)
385-389: LGTM with minor observation.The propagation of
remove_confined_accountsfromconfig.chainlinktochainlink_configis correct. Consider whether future fields should follow the same pattern or if a more systematic approach (e.g., deriving from the same config source) would be cleaner.
394-404: LGTM!The
ChainlinkImpl::try_new_from_endpointscall correctly passes&config.chainlinkas the final argument, aligning with the updated constructor signature.magicblock-chainlink/src/remote_account_provider/config.rs (5)
1-4: LGTM!Imports for
HashSetandPubkeyare correctly added to support the newprogram_subsfield.
14-23: LGTM!The new
program_subsfield is well-documented as a backup subscription mechanism for program accounts. The documentation clearly explains its purpose.
47-52: LGTM!Using
..Default::default()intry_new_with_metricsensures forward compatibility when new fields are added to the struct.
73-76: LGTM!The accessor returns a reference to the
HashSet, which is appropriate for read-only access.
79-88: LGTM!The default implementation correctly initializes
program_subswithdlp::id()(the delegation program), which is a sensible default for the subscription backup mechanism.magicblock-chainlink/src/remote_account_provider/chain_pubsub_client.rs (6)
17-20: LGTM!Imports correctly added for the new program subscription types:
RpcProgramAccountsConfigandRpcKeyedAccount.
39-42: LGTM!The
ProgramSubscribeResulttype alias mirrors the existingSubscribeResultpattern, maintaining consistency in the codebase.
154-157: LGTM!The
subscribe_programmethod is correctly added to theChainPubsubClienttrait with a consistent signature pattern.
254-270: LGTM!The
subscribe_programimplementation correctly:
- Uses the actor message pattern consistent with
subscribe- Sends
ChainPubsubActorMessage::ProgramSubscribe- Includes appropriate error logging with
inspect_err
455-469: LGTM!The mock implementation correctly:
- Checks connection state before allowing subscription
- Returns appropriate error when disconnected
- Documents that program subscriptions don't track individual accounts in the mock
89-110: Unsafe lifetime extension consistently applied across subscription methods.Both
account_subscribe(lines 80–85) andprogram_subscribe(lines 103–108) use identical unsafe transmute patterns to extend stream lifetimes to'static. The safety comments are consistent and correctly document the reasoning: the stream depends on the client instance, which is only dropped when the connection terminates, at which point the stream is discarded regardless.magicblock-chainlink/src/chainlink/mod.rs (4)
13-13: LGTM!Import addition for
ChainLinkConfigis correctly placed and aligns with the config-based parameter refactoring.
65-68: LGTM!The
remove_confined_accountsfield is well-documented and correctly typed. The blank line before the doc comment improves readability.
73-99: LGTM - Config-based initialization is cleaner.The signature change from individual parameters to
&ChainLinkConfigimproves API ergonomics and extensibility. Field initialization from config is straightforward.
102-151: LGTM!The
try_new_from_endpointssignature update correctly propagateschainlink_configto the innertry_newcall, maintaining consistency across the initialization paths.magicblock-chainlink/src/submux/mod.rs (5)
140-142: LGTM!The
program_subsfield correctly usesArc<Mutex<HashSet<Pubkey>>>for thread-safe sharing across reconnection tasks, consistent with the existingsubscriptionspattern.
205-228: LGTM!Initialization and propagation of
program_substhrough the reconnector spawn path is correctly wired. The clone before passing to spawn ensures each task has its own Arc reference.
240-268: LGTM!The
spawn_reconnectorsfunction correctly clonesprogram_subsfor each client's reconnection task, ensuring the shared state is accessible during reconnection attempts.
641-662: LGTM - Resilient subscription pattern correctly implemented.The
subscribe_programmethod correctly adds toprogram_subsbefore attempting the subscription, ensuring reconnection logic will retry failed subscriptions. This aligns with the established pattern per project learnings.The
warn!log level for existing subscriptions is appropriate as it indicates a potential logic issue in the caller without being an error.
330-343: Consider whether program resubscription failure should abort the entire reconnect.Currently, if any single program subscription fails during reconnect, the entire reconnect is considered failed and will be retried. This is conservative but may cause unnecessary retry loops if a single program consistently fails to subscribe while others succeed.
Consider whether partial success (logging the failure but continuing with other programs) would be more resilient, similar to how account subscription failures are handled in some systems.
⛔ Skipped due to learnings
Learnt from: thlorenz Repo: magicblock-labs/magicblock-validator PR: 703 File: magicblock-chainlink/src/submux/mod.rs:652-654 Timestamp: 2025-12-01T16:02:05.367Z Learning: In magicblock-chainlink/src/submux/mod.rs, the subscribe_program method intentionally adds program_id to program_subs before attempting the subscription. This ensures that even if the initial subscription fails or only partially succeeds across clients, the reconnection logic will retry the subscription. This is a deliberate design pattern for resilience in the multi-client architecture and should not be "fixed" to remove entries on failure.Learnt from: thlorenz Repo: magicblock-labs/magicblock-validator PR: 621 File: magicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rs:457-495 Timestamp: 2025-11-07T14:20:31.457Z Learning: In magicblock-chainlink/src/remote_account_provider/chain_pubsub_client.rs, the unsubscribe closure returned by PubSubConnection::account_subscribe(...) resolves to () (unit), not a Result. Downstream code should not attempt to inspect an unsubscribe result and can optionally wrap it in a timeout to guard against hangs.magicblock-task-scheduler/src/service.rs (5)
10-21: LGTM!Import reorganization correctly brings in
RpcClientfromsolana_rpc_client::nonblockingand splits SDK types into their respective crates (solana_instruction,solana_message, etc.).
33-50: LGTM!The struct field change from
tx_scheduler: TransactionSchedulerHandletorpc_client: RpcClientcorrectly reflects the architectural shift to using RPC for transaction submission.
52-55: LGTM!Boxing
TaskSchedulerErrorinRecoverableis appropriate since RPC client errors can be large, and this avoids bloating the enum variant size.
64-97: LGTM!Constructor correctly accepts
RpcClientand returnsTaskSchedulerResult<Self>. The initialization path remains unchanged except for the field name.
301-329: The error type compatibility is correctly implemented.TaskSchedulerErrorhas anRpcvariant that acceptsBox<solana_rpc_client_api::client_error::Error>with the#[from]attribute, which auto-generates theFromimplementation. Themap_err(Box::new)call properly convertsClientErrortoBox<ClientError>, which is then automatically converted toTaskSchedulerError::Rpc.magicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rs (7)
14-17: LGTM!Import additions for
RpcProgramAccountsConfigandResponsealias are correctly placed for the new program subscription functionality.
84-86: LGTM!The
program_subsfield mirrors thesubscriptionsfield structure, maintaining consistency in how account and program subscriptions are tracked.
101-125: LGTM - Well-documented message variants.The
ProgramSubscribevariant is well-documented with the important note that only updates for accounts also insubscriptionswill be forwarded. This documents the intentional filtering behavior.
176-192: LGTM!Shutdown correctly drains both
subscriptionsandprogram_subsusing iterator chaining, ensuring all subscription tasks are cancelled cleanly.
522-653: LGTM - Program subscription implementation is well-structured.The
add_program_subfunction correctly:
- Checks for existing subscriptions to avoid duplicates
- Inserts cancellation token before async subscription to prevent race conditions
- Filters updates to only forward accounts that are also directly subscribed (lines 609)
- Handles EOF by signaling connection issues
- Cleans up with timeout on unsubscribe
The filtering at line 609 implements the documented behavior from the enum variant comment.
712-732: Good refactoring - DRY improvement for subscription draining.The
drain_subscriptionshelper function reduces code duplication and makes the abort logic cleaner. The function correctly:
- Takes ownership of all subscriptions via
std::mem::take- Cancels each subscription's token
- Logs the count of cancelled subscriptions
604-620: Potential performance concern with lock acquisition in hot path.The
subs.lock()call inside the update loop (line 609) acquires a mutex lock for every program account update. If the program has many accounts with frequent updates, this could become a bottleneck.Consider caching the subscribed accounts set periodically or using a read-optimized concurrent data structure if performance becomes an issue.
⛔ Skipped due to learnings
Learnt from: bmuddha Repo: magicblock-labs/magicblock-validator PR: 589 File: magicblock-processor/src/scheduler/coordinator.rs:227-238 Timestamp: 2025-11-07T13:20:13.793Z Learning: In magicblock-processor's ExecutionCoordinator (scheduler/coordinator.rs), the `account_contention` HashMap intentionally does not call `shrink_to_fit()`. Maintaining slack capacity is beneficial for performance by avoiding frequent reallocations during high transaction throughput. As long as empty entries are removed from the map (which `clear_account_contention` does), the capacity overhead is acceptable.Learnt from: thlorenz Repo: magicblock-labs/magicblock-validator PR: 703 File: magicblock-chainlink/src/submux/mod.rs:652-654 Timestamp: 2025-12-01T16:02:05.367Z Learning: In magicblock-chainlink/src/submux/mod.rs, the subscribe_program method intentionally adds program_id to program_subs before attempting the subscription. This ensures that even if the initial subscription fails or only partially succeeds across clients, the reconnection logic will retry the subscription. This is a deliberate design pattern for resilience in the multi-client architecture and should not be "fixed" to remove entries on failure.Learnt from: bmuddha Repo: magicblock-labs/magicblock-validator PR: 578 File: magicblock-accounts-db/src/lib.rs:63-72 Timestamp: 2025-10-21T10:34:59.140Z Learning: In magicblock-validator, the AccountsDb "stop-the-world" synchronizer is managed at the processor/executor level, not at the AccountsDb API level. Transaction executors in magicblock-processor hold a read lock (sync.read()) for the duration of each slot and release it only at slot boundaries, ensuring all account writes happen under the read lock. Snapshot operations acquire a write lock, blocking until all executors release their read locks. This pattern ensures mutual exclusion between writes and snapshots without requiring read guards in AccountsDb write APIs.Learnt from: thlorenz Repo: magicblock-labs/magicblock-validator PR: 621 File: magicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rs:457-495 Timestamp: 2025-11-07T14:20:31.457Z Learning: In magicblock-chainlink/src/remote_account_provider/chain_pubsub_client.rs, the unsubscribe closure returned by PubSubConnection::account_subscribe(...) resolves to () (unit), not a Result. Downstream code should not attempt to inspect an unsubscribe result and can optionally wrap it in a timeout to guard against hangs.
Dodecahedr0x
force-pushed
the
dode/schedule-with-rpc
branch
from
d880a89 to
ff66c7b
Compare
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-task-scheduler/src/service.rs (1)
33-50: RpcClient injection intoTaskSchedulerServicelooks good; consider refreshing surrounding commentsThe new
rpc_client: RpcClientfield and corresponding constructor parameter cleanly decouple the scheduler from the old executor and align with the “send crank txs via RPC” objective. Struct initialization innewis consistent and there are no ownership/lifetime issues.Two small follow‑ups for clarity:
- Line 38:
scheduled_tasks’s doc string still mentions “transaction executor”, which is no longer accurate with the new wiring.- Lines 57‑60: the SAFETY comment still refers to
TransactionSchedulerHandle; updating it to mentionRpcClient(and dropping obsolete types) will keep the unsafe justification in sync with the actual fields.Also applies to: 64-71, 87-90
♻️ Duplicate comments (1)
magicblock-magic-program-api/src/instruction.rs (1)
103-105: Clarify the semantics of the Noop(u64) payload
Noop(u64)is now part of the public instruction API, but the doc comment doesn’t explain what theu64represents or whether it’s ignored by the processor (currently matched asNoop(_)). Expanding the docs will help callers understand if this is simply a nonce/unique identifier or reserved for future use.You could apply something along these lines:
- /// Noop instruction - Noop(u64), + /// Noop instruction (no operation). + /// + /// The `u64` payload is not interpreted by the program and can be used + /// by callers as a nonce/unique identifier (e.g. for tests or tx hashing). + /// It is currently ignored during execution. + Noop(u64),
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (3)
Cargo.lockis excluded by!**/*.locktest-integration/Cargo.lockis excluded by!**/*.locktest-integration/programs/noop/noop.sois excluded by!**/*.so
📒 Files selected for processing (22)
.github/actions/setup-build-env/action.yml(1 hunks)Cargo.toml(1 hunks)magicblock-account-cloner/src/lib.rs(1 hunks)magicblock-ledger/Cargo.toml(1 hunks)magicblock-magic-program-api/src/instruction.rs(1 hunks)magicblock-processor/src/executor/mod.rs(1 hunks)magicblock-processor/src/scheduler.rs(1 hunks)magicblock-task-scheduler/src/service.rs(9 hunks)programs/magicblock/src/magicblock_processor.rs(1 hunks)programs/magicblock/src/schedule_task/process_schedule_task.rs(1 hunks)programs/magicblock/src/test_utils/mod.rs(0 hunks)programs/magicblock/src/utils/instruction_utils.rs(1 hunks)test-integration/configs/schedule-task.devnet.toml(0 hunks)test-integration/test-task-scheduler/src/lib.rs(1 hunks)test-integration/test-task-scheduler/tests/test_cancel_ongoing_task.rs(2 hunks)test-integration/test-task-scheduler/tests/test_reschedule_task.rs(2 hunks)test-integration/test-task-scheduler/tests/test_schedule_error.rs(2 hunks)test-integration/test-task-scheduler/tests/test_schedule_task.rs(2 hunks)test-integration/test-task-scheduler/tests/test_schedule_task_signed.rs(2 hunks)test-integration/test-task-scheduler/tests/test_scheduled_commits.rs(2 hunks)test-integration/test-task-scheduler/tests/test_unauthorized_reschedule.rs(2 hunks)test-kit/src/lib.rs(0 hunks)
💤 Files with no reviewable changes (3)
- test-kit/src/lib.rs
- programs/magicblock/src/test_utils/mod.rs
- test-integration/configs/schedule-task.devnet.toml
🧰 Additional context used
🧠 Learnings (16)
📓 Common learnings
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 614
File: magicblock-task-scheduler/src/db.rs:26-0
Timestamp: 2025-11-12T09:46:27.553Z
Learning: In magicblock-task-scheduler, task parameter validation (including ensuring iterations > 0 and enforcing minimum execution intervals) is performed in the Magic program (on-chain) before ScheduleTaskRequest instances reach the scheduler service. The From<&ScheduleTaskRequest> conversion in db.rs does not need additional validation because inputs are already validated at the program level.
📚 Learning: 2025-11-07T13:09:52.253Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: test-kit/src/lib.rs:275-0
Timestamp: 2025-11-07T13:09:52.253Z
Learning: In test-kit, the transaction scheduler in ExecutionTestEnv is not expected to shut down during tests. Therefore, using `.unwrap()` in test helper methods like `schedule_transaction` is acceptable and will not cause issues in the test environment.
Applied to files:
test-integration/test-task-scheduler/tests/test_unauthorized_reschedule.rstest-integration/test-task-scheduler/tests/test_schedule_error.rstest-integration/test-task-scheduler/src/lib.rstest-integration/test-task-scheduler/tests/test_schedule_task.rstest-integration/test-task-scheduler/tests/test_cancel_ongoing_task.rstest-integration/test-task-scheduler/tests/test_reschedule_task.rstest-integration/test-task-scheduler/tests/test_scheduled_commits.rsmagicblock-task-scheduler/src/service.rstest-integration/test-task-scheduler/tests/test_schedule_task_signed.rs
📚 Learning: 2025-10-14T09:56:14.047Z
Learnt from: taco-paco
Repo: magicblock-labs/magicblock-validator PR: 564
File: test-integration/programs/flexi-counter/src/processor/call_handler.rs:122-125
Timestamp: 2025-10-14T09:56:14.047Z
Learning: The file test-integration/programs/flexi-counter/src/processor/call_handler.rs contains a test smart contract used for integration testing, not production code.
Applied to files:
test-integration/test-task-scheduler/tests/test_unauthorized_reschedule.rstest-integration/test-task-scheduler/tests/test_schedule_error.rsprograms/magicblock/src/schedule_task/process_schedule_task.rstest-integration/test-task-scheduler/src/lib.rstest-integration/test-task-scheduler/tests/test_schedule_task.rstest-integration/test-task-scheduler/tests/test_cancel_ongoing_task.rstest-integration/test-task-scheduler/tests/test_reschedule_task.rstest-integration/test-task-scheduler/tests/test_scheduled_commits.rstest-integration/test-task-scheduler/tests/test_schedule_task_signed.rs
📚 Learning: 2025-12-03T09:33:48.707Z
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 639
File: test-integration/test-committor-service/tests/test_ix_commit_local.rs:867-881
Timestamp: 2025-12-03T09:33:48.707Z
Learning: Repo: magicblock-labs/magicblock-validator PR: 639
Context: test-integration/test-committor-service/tests/test_ix_commit_local.rs (ix_commit_local)
Learning: The PhotonIndexer used for compressed account fetches (get_compressed_account) has built‑in retry logic (defaults to ~10 attempts), so tests should not add separate retry loops around compressed fetches unless there’s a specific need.
Applied to files:
test-integration/test-task-scheduler/tests/test_unauthorized_reschedule.rstest-integration/test-task-scheduler/tests/test_schedule_error.rstest-integration/test-task-scheduler/src/lib.rstest-integration/test-task-scheduler/tests/test_schedule_task.rstest-integration/test-task-scheduler/tests/test_cancel_ongoing_task.rstest-integration/test-task-scheduler/tests/test_reschedule_task.rstest-integration/test-task-scheduler/tests/test_scheduled_commits.rsmagicblock-account-cloner/src/lib.rstest-integration/test-task-scheduler/tests/test_schedule_task_signed.rs
📚 Learning: 2025-11-19T09:34:37.917Z
Learnt from: thlorenz
Repo: magicblock-labs/magicblock-validator PR: 621
File: test-integration/test-chainlink/tests/ix_remote_account_provider.rs:62-63
Timestamp: 2025-11-19T09:34:37.917Z
Learning: In test-integration/test-chainlink/tests/ix_remote_account_provider.rs and similar test files, the `_fwd_rx` receiver returned by `init_remote_account_provider()` is intentionally kept alive (but unused) to prevent "receiver dropped" errors on the sender side. The pattern `let (remote_account_provider, _fwd_rx) = init_remote_account_provider().await;` should NOT be changed to `let (remote_account_provider, _) = ...` because dropping the receiver would cause send() operations to fail.
Applied to files:
test-integration/test-task-scheduler/tests/test_unauthorized_reschedule.rstest-integration/test-task-scheduler/tests/test_schedule_error.rstest-integration/test-task-scheduler/src/lib.rstest-integration/test-task-scheduler/tests/test_schedule_task.rstest-integration/test-task-scheduler/tests/test_cancel_ongoing_task.rstest-integration/test-task-scheduler/tests/test_reschedule_task.rstest-integration/test-task-scheduler/tests/test_scheduled_commits.rstest-integration/test-task-scheduler/tests/test_schedule_task_signed.rs
📚 Learning: 2025-12-03T09:36:01.527Z
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 639
File: magicblock-chainlink/src/remote_account_provider/mod.rs:1350-1353
Timestamp: 2025-12-03T09:36:01.527Z
Learning: Repo: magicblock-labs/magicblock-validator
File: magicblock-chainlink/src/remote_account_provider/mod.rs
Context: consolidate_fetched_remote_accounts
Learning: For unexpected result counts (>2), the project prefers logging an error and returning an empty Vec over panicking; acceptable during development per maintainer (Dodecahedr0x).
Applied to files:
test-integration/test-task-scheduler/tests/test_unauthorized_reschedule.rstest-integration/test-task-scheduler/tests/test_schedule_error.rstest-integration/test-task-scheduler/tests/test_cancel_ongoing_task.rstest-integration/test-task-scheduler/tests/test_schedule_task_signed.rs
📚 Learning: 2025-11-12T09:46:27.553Z
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 614
File: magicblock-task-scheduler/src/db.rs:26-0
Timestamp: 2025-11-12T09:46:27.553Z
Learning: In magicblock-task-scheduler, task parameter validation (including ensuring iterations > 0 and enforcing minimum execution intervals) is performed in the Magic program (on-chain) before ScheduleTaskRequest instances reach the scheduler service. The From<&ScheduleTaskRequest> conversion in db.rs does not need additional validation because inputs are already validated at the program level.
Applied to files:
test-integration/test-task-scheduler/tests/test_schedule_error.rsprograms/magicblock/src/schedule_task/process_schedule_task.rsmagicblock-task-scheduler/src/service.rsmagicblock-account-cloner/src/lib.rs
📚 Learning: 2025-11-20T17:25:23.444Z
Learnt from: JMirval
Repo: magicblock-labs/magicblock-validator PR: 656
File: programs/guinea/src/lib.rs:33-33
Timestamp: 2025-11-20T17:25:23.444Z
Learning: In the magicblock-validator codebase, task IDs (task_id) are i64 values that can be negative. The task scheduler is designed to handle any i64 value including negative task IDs. Task IDs are randomly generated using rand::random() which produces values across the full i64 range. No validation is needed to restrict task IDs to positive values.
Applied to files:
test-integration/test-task-scheduler/tests/test_schedule_error.rstest-integration/test-task-scheduler/src/lib.rstest-integration/test-task-scheduler/tests/test_schedule_task.rstest-integration/test-task-scheduler/tests/test_reschedule_task.rsmagicblock-task-scheduler/src/service.rstest-integration/test-task-scheduler/tests/test_schedule_task_signed.rs
📚 Learning: 2025-11-04T10:53:50.922Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: magicblock-processor/src/scheduler/locks.rs:110-122
Timestamp: 2025-11-04T10:53:50.922Z
Learning: In magicblock-processor, the TransactionScheduler runs in a single, dedicated thread and will always remain single-threaded. The `next_transaction_id()` function in scheduler/locks.rs uses `unsafe static mut` which is safe given this architectural guarantee.
Applied to files:
magicblock-processor/src/scheduler.rsmagicblock-task-scheduler/src/service.rs
📚 Learning: 2025-10-21T11:00:18.396Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 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-processor/src/scheduler.rs
📚 Learning: 2025-11-13T09:38:43.804Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: magicblock-processor/src/scheduler/locks.rs:64-102
Timestamp: 2025-11-13T09:38:43.804Z
Learning: In magicblock-processor's TransactionScheduler (scheduler/mod.rs line 59), the executor count is clamped to MAX_SVM_EXECUTORS (63) at initialization time, and executor IDs are assigned sequentially from 0 to count-1. This architectural guarantee ensures that executor IDs used in the bitmask-based AccountLock (scheduler/locks.rs) will always be within valid bounds for bit shifting operations, making runtime bounds checks unnecessary.
Applied to files:
magicblock-processor/src/scheduler.rsmagicblock-task-scheduler/src/service.rs
📚 Learning: 2025-11-07T13:20:13.793Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: magicblock-processor/src/scheduler/coordinator.rs:227-238
Timestamp: 2025-11-07T13:20:13.793Z
Learning: In magicblock-processor's ExecutionCoordinator (scheduler/coordinator.rs), the `account_contention` HashMap intentionally does not call `shrink_to_fit()`. Maintaining slack capacity is beneficial for performance by avoiding frequent reallocations during high transaction throughput. As long as empty entries are removed from the map (which `clear_account_contention` does), the capacity overhead is acceptable.
Applied to files:
magicblock-processor/src/scheduler.rs
📚 Learning: 2025-10-28T13:15:42.706Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 596
File: magicblock-processor/src/scheduler.rs:1-1
Timestamp: 2025-10-28T13:15:42.706Z
Learning: In magicblock-processor, transaction indexes were always set to 0 even before the changes in PR #596. The proper transaction indexing within slots will be addressed during the planned ledger rewrite.
Applied to files:
magicblock-processor/src/scheduler.rs
📚 Learning: 2025-11-24T14:21:00.996Z
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 639
File: Cargo.toml:58-58
Timestamp: 2025-11-24T14:21:00.996Z
Learning: In the magicblock-validator codebase, magicblock-api/Cargo.toml intentionally uses borsh = "1.5.3" (instead of the workspace version 0.10.4) because it needs to deserialize types from the magic-domain-program external dependency, which requires borsh 1.5.x compatibility. This is an intentional exception for interoperability with the magic domain program.
Applied to files:
magicblock-ledger/Cargo.tomlCargo.toml
📚 Learning: 2025-11-21T10:22:07.520Z
Learnt from: taco-paco
Repo: magicblock-labs/magicblock-validator PR: 661
File: magicblock-committor-service/src/intent_executor/single_stage_executor.rs:20-28
Timestamp: 2025-11-21T10:22:07.520Z
Learning: In magicblock-committor-service's SingleStageExecutor and TwoStageExecutor (single_stage_executor.rs and two_stage_executor.rs), the fields transaction_strategy, junk, and patched_errors are intentionally public because these executors are designed to be used independently outside of the IntentExecutor scope, and callers need access to these execution reports for cleanup and error handling.
Applied to files:
magicblock-task-scheduler/src/service.rs
📚 Learning: 2025-11-24T08:45:11.164Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 675
File: Cargo.toml:145-145
Timestamp: 2025-11-24T08:45:11.164Z
Learning: The reqwest dependency version 0.11 is intentionally used in the magicblock-validator project to maintain compatibility with the Solana client dependencies.
Applied to files:
Cargo.toml
🧬 Code graph analysis (8)
test-integration/test-task-scheduler/tests/test_unauthorized_reschedule.rs (3)
test-integration/test-task-scheduler/src/lib.rs (2)
create_delegated_counter(75-124)setup_validator(35-73)test-integration/schedulecommit/client/src/schedule_commit_context.rs (1)
ephem_blockhash(282-284)test-integration/test-tools/src/integration_test_context.rs (1)
try_get_latest_blockhash_ephem(1085-1087)
test-integration/test-task-scheduler/tests/test_schedule_error.rs (3)
test-integration/test-task-scheduler/src/lib.rs (2)
create_delegated_counter(75-124)setup_validator(35-73)test-integration/schedulecommit/client/src/schedule_commit_context.rs (1)
ephem_blockhash(282-284)test-integration/test-tools/src/integration_test_context.rs (1)
try_get_latest_blockhash_ephem(1085-1087)
programs/magicblock/src/schedule_task/process_schedule_task.rs (2)
programs/magicblock/src/test_utils/mod.rs (1)
process_instruction(42-59)programs/magicblock/src/utils/instruction_utils.rs (1)
noop_instruction(285-291)
test-integration/test-task-scheduler/tests/test_schedule_task.rs (3)
test-integration/test-task-scheduler/src/lib.rs (1)
setup_validator(35-73)test-integration/schedulecommit/client/src/schedule_commit_context.rs (1)
ephem_blockhash(282-284)test-integration/test-tools/src/integration_test_context.rs (1)
try_get_latest_blockhash_ephem(1085-1087)
test-integration/test-task-scheduler/tests/test_cancel_ongoing_task.rs (2)
test-integration/schedulecommit/client/src/schedule_commit_context.rs (1)
ephem_blockhash(282-284)test-integration/test-tools/src/integration_test_context.rs (1)
try_get_latest_blockhash_ephem(1085-1087)
test-integration/test-task-scheduler/tests/test_reschedule_task.rs (2)
test-integration/schedulecommit/client/src/schedule_commit_context.rs (1)
ephem_blockhash(282-284)test-integration/test-tools/src/integration_test_context.rs (1)
try_get_latest_blockhash_ephem(1085-1087)
magicblock-task-scheduler/src/service.rs (2)
programs/magicblock/src/validator.rs (2)
validator_authority(26-33)validator_authority_id(35-42)programs/magicblock/src/utils/instruction_utils.rs (1)
noop_instruction(285-291)
test-integration/test-task-scheduler/tests/test_schedule_task_signed.rs (3)
test-integration/test-task-scheduler/src/lib.rs (2)
create_delegated_counter(75-124)setup_validator(35-73)test-integration/schedulecommit/client/src/schedule_commit_context.rs (1)
ephem_blockhash(282-284)test-integration/test-tools/src/integration_test_context.rs (1)
try_get_latest_blockhash_ephem(1085-1087)
🔇 Additional comments (19)
.github/actions/setup-build-env/action.yml (1)
30-37: The addition oflibclang-devis necessary and correctly placed.RocksDB is a workspace dependency that uses
rocksdb-sysfor C bindings, which requireslibclang-devheaders to compile successfully. The Cargo.toml explicitly references rocksdb-sys and includes a comment about build compatibility. This dependency addition aligns with the recent RocksDB patch (0.23.0) and is not optional—it's required for the build to succeed on Linux.magicblock-ledger/Cargo.toml (1)
33-33: No issues found with rocksdb workspace dependency reference.The rocksdb dependency in magicblock-ledger correctly uses
workspace = true. The root Cargo.toml intentionally overrides the workspace.dependencies.rocksdb with a git source (parent commit d4e9e16 of rocksdb 0.23.0) to resolve Solana version conflicts. This override is documented and marked for removal once Solana is upgraded to 2.3. The inline features declaration in magicblock-ledger matches the workspace configuration.Cargo.toml (2)
190-193: Verify solana-svm revision 3e9456ec4 for compatibility and stability.The solana-svm revision has been updated to 3e9456ec4, which is currently associated with PR 10 in the magicblock-svm repository. Confirm that this commit is stable and does not introduce breaking changes to the magicblock-svm fork or dependent crates in the workspace.
195-212: Rocksdb version mismatch is intentional but pending resolution.The workspace declares rocksdb
0.22.0but patches it to git revd4e9e16(a parent commit of0.23.0) specifically to avoid linker conflicts with solana dependencies. Onlymagicblock-ledgerdirectly uses rocksdb in the workspace, and it correctly inherits the lz4 feature from the workspace dependency.The configuration is documented and intentional. However, the TODO to remove this patch upon solana 2.3 upgrade should reference a tracked issue or sprint plan for visibility and accountability.
magicblock-processor/src/executor/mod.rs (1)
242-252: ClarifyForkGraph::relationshipdirection and forkless assumptionThe linear ordering (
a < b→Ancestor,a > b→Descendant,a == b→Equal) looks sensible for a forkless chain, but correctness depends on howForkGraph::relationship(a, b)defines the relation (i.e., “relation ofatob” vs the inverse). Please double‑check this againstsolana_program_runtime::loaded_programs::ForkGraph/BlockRelationdocs and confirm that:
- the direction (
avsb) matches Solana’s expectation, and- assuming a strictly linear, forkless slot sequence is acceptable for all current uses of
SimpleForkGraph(e.g., no future support for reorgs/forks relying on this).programs/magicblock/src/magicblock_processor.rs (1)
35-81: Noop arm correctly wired as a pure no-opThe new
Noop(_) => Ok(())arm cleanly handles the added enum variant without touching accounts or altering existing flows. This is a safe, backwards-compatible extension of the instruction dispatcher.programs/magicblock/src/schedule_task/process_schedule_task.rs (1)
155-164: Tests now use shared Noop helper with unchanged semanticsSwitching
create_simple_ixtoInstructionUtils::noop_instruction(0)preserves the “no accounts, no signers” behavior of the simple test instruction while centralizing Noop construction. This keeps the schedule‑task tests aligned with the on‑chain validation invariants (interval, iterations, non‑empty instructions) that the scheduler service relies on.Based on learnings, this keeps validation where it belongs in the Magic program.
programs/magicblock/src/utils/instruction_utils.rs (1)
282-291: Noop helper is correctly scoped and implemented
InstructionUtils::noop_instructioncleanly wrapsMagicBlockInstruction::Noop(data)with the program’s ID and no account metas, providing a single canonical way to build MagicBlock no-op instructions for tests and callers.test-integration/test-task-scheduler/tests/test_schedule_error.rs (1)
12-12: Use ephem blockhash helper instead of NOOP helperImporting
setup_validator/create_delegated_counterand switching toctx.try_get_latest_blockhash_ephem()is consistent with the new pattern across tests and removes the NOOP dependency without changing the test’s semantics.Also applies to: 31-32
test-integration/test-task-scheduler/src/lib.rs (1)
29-30: solana_sdk import now matches actual usageTrimming the
solana_sdkimport list down to the types used in this module is correct and keeps the dependency surface clean.test-integration/test-task-scheduler/tests/test_unauthorized_reschedule.rs (1)
11-11: Align unauthorized-reschedule test with shared helpers and ephem blockhash APIUsing
setup_validator/create_delegated_counterplusctx.try_get_latest_blockhash_ephem()standardizes setup and ephem blockhash retrieval across the suite while preserving the unauthorized-reschedule behavior being asserted here.Also applies to: 35-36
test-integration/test-task-scheduler/tests/test_cancel_ongoing_task.rs (1)
12-12: Switch cancel-ongoing-task test to ctx.try_get_latest_blockhash_ephemThe new import and use of
ctx.try_get_latest_blockhash_ephem()remove the NOOP transaction dependency while keeping the test’s scheduling and cancellation behavior intact.Also applies to: 30-31
test-integration/test-task-scheduler/tests/test_reschedule_task.rs (1)
12-12: Use shared helpers and ephem blockhash helper in reschedule testThe refactor to
setup_validator/create_delegated_counterandctx.try_get_latest_blockhash_ephem()simplifies setup and keeps the reschedule assertions unchanged.Also applies to: 30-31
test-integration/test-task-scheduler/tests/test_schedule_task_signed.rs (1)
10-10: Standardize signed-schedule test on ephem blockhash helperUsing
setup_validator/create_delegated_counterandctx.try_get_latest_blockhash_ephem()matches the rest of the suite and doesn’t change the expectedMissingRequiredSignaturebehavior.Also applies to: 25-26
test-integration/test-task-scheduler/tests/test_schedule_task.rs (1)
12-12: Migrate schedule-task test to shared setup and ephem blockhash APIThe new helper import and
ctx.try_get_latest_blockhash_ephem()usage are consistent with other tests and keep the end-to-end scheduling/cancellation and DB checks intact.Also applies to: 30-31
test-integration/test-task-scheduler/tests/test_scheduled_commits.rs (1)
10-10: Use shared helpers and ephem blockhash helper in scheduled-commits testThe import update and
ctx.try_get_latest_blockhash_ephem()call are consistent with the rest of the suite and keep the test logic straightforward.Also applies to: 25-26
magicblock-processor/src/scheduler.rs (1)
142-152: Verifyprunesecond parameter and confirmlatest_root_slotredundancyThe locking consolidation is good, but the hardcoded
0passed tocache.prune(root, 0)needs verification.LatestBlockcontainsclock: Clock, which has anepochfield — you likely need to passself.latest_block.load().clock.epochinstead of0as the second argument to match the actual epoch of the block being processed.Additionally, check your local
solana-program-runtimev2.2.1 to confirm whetherProgramCache::pruneupdateslatest_root_slotinternally. If it does, the explicitcache.latest_root_slot = root;assignment is redundant. If not, add a comment explaining why the manual assignment is necessary to prevent future cleanup.magicblock-task-scheduler/src/service.rs (2)
52-55: Boxing recoverable errors is reasonable and run‑loop handling remains consistentChanging
ProcessingOutcome::Recoverableto carryBox<TaskSchedulerError>and wrapping errors inprocess_requestpreserves the previous control flow while avoiding copies of potentially large error values. Therunloop’s match onProcessingOutcomestill cleanly distinguishes recoverable vs fatal paths.No functional issues spotted here.
Also applies to: 123-165, 260-283
301-321: Noop prefix for transaction uniqueness withAtomicU64is soundUsing
InstructionUtils::noop_instruction(self.tx_counter.fetch_add(1, Ordering::Relaxed))to prepend a unique noop instruction achieves per‑tx uniqueness without affecting task instructions. Given the scheduler is confined to a single Tokio task (per the SAFETY comment),AtomicU64with relaxed ordering is sufficient here.
Dodecahedr0x
force-pushed
the
dode/schedule-with-rpc
branch
from
ff66c7b to
1bb3bb5
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
magicblock-api/src/magic_validator.rs (1)
279-297: Consider passing a higher‑level config handle instead of a raw RPC URL String
TaskSchedulerService::newnow takesconfig.listen.http()as aString, which leaks knowledge of how the validator constructs its local RPC endpoint into the scheduler API. Long‑term, you might want to pass eitherconfig.listen(BindAddress) or a smallTaskSchedulerRpcConfigstruct and let the scheduler decide how to materialize the client URL, to reduce coupling between layers.magicblock-task-scheduler/src/service.rs (1)
57-62: Update unsafeSend/Synccomment to reflect current fieldsThe safety comment still names
TransactionSchedulerHandle, but the struct now holds anRpcClientinstead. For future maintainers reviewing the unsafeSend/Syncimpls, please update the comment to list the current fields (includingRpcClient) so the justification matches the actual struct layout.
♻️ Duplicate comments (1)
magicblock-task-scheduler/src/service.rs (1)
301-329: Use theSignaturereturned byRpcClient::send_transactionand make RPC error mapping explicit
process_transactionderives the signature fromtx.signatures[0]and ignores theSignaturereturned bysend_transaction, while relying onmap_err(Box::new)?plus the#[from] Box<...::Error>onTaskSchedulerError::Rpc. This duplicates the source of truth for the signature and hides the error mapping behind an extra boxing step.You can simplify and make this clearer by using the returned signature and constructing the error variant directly:
- let sig = tx.signatures[0]; - self.rpc_client - .send_transaction(&tx) - .await - .map_err(Box::new)?; - Ok(sig) + self.rpc_client + .send_transaction(&tx) + .await + .map_err(|e| TaskSchedulerError::Rpc(Box::new(e)))This uses the actual RPC response signature and documents the error conversion in one place.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (2)
Cargo.lockis excluded by!**/*.locktest-integration/Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (8)
magicblock-api/src/magic_validator.rs(1 hunks)magicblock-config/src/types/network.rs(1 hunks)magicblock-task-scheduler/Cargo.toml(1 hunks)magicblock-task-scheduler/src/db.rs(13 hunks)magicblock-task-scheduler/src/errors.rs(1 hunks)magicblock-task-scheduler/src/service.rs(8 hunks)magicblock-task-scheduler/tests/service.rs(0 hunks)test-integration/programs/schedulecommit/src/api.rs(1 hunks)
💤 Files with no reviewable changes (1)
- magicblock-task-scheduler/tests/service.rs
🧰 Additional context used
🧠 Learnings (20)
📓 Common learnings
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 614
File: magicblock-task-scheduler/src/db.rs:26-0
Timestamp: 2025-11-12T09:46:27.553Z
Learning: In magicblock-task-scheduler, task parameter validation (including ensuring iterations > 0 and enforcing minimum execution intervals) is performed in the Magic program (on-chain) before ScheduleTaskRequest instances reach the scheduler service. The From<&ScheduleTaskRequest> conversion in db.rs does not need additional validation because inputs are already validated at the program level.
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: test-kit/src/lib.rs:275-0
Timestamp: 2025-11-07T13:09:52.253Z
Learning: In test-kit, the transaction scheduler in ExecutionTestEnv is not expected to shut down during tests. Therefore, using `.unwrap()` in test helper methods like `schedule_transaction` is acceptable and will not cause issues in the test environment.
📚 Learning: 2025-11-24T14:21:00.996Z
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 639
File: Cargo.toml:58-58
Timestamp: 2025-11-24T14:21:00.996Z
Learning: In the magicblock-validator codebase, magicblock-api/Cargo.toml intentionally uses borsh = "1.5.3" (instead of the workspace version 0.10.4) because it needs to deserialize types from the magic-domain-program external dependency, which requires borsh 1.5.x compatibility. This is an intentional exception for interoperability with the magic domain program.
Applied to files:
magicblock-task-scheduler/Cargo.toml
📚 Learning: 2025-11-12T09:46:27.553Z
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 614
File: magicblock-task-scheduler/src/db.rs:26-0
Timestamp: 2025-11-12T09:46:27.553Z
Learning: In magicblock-task-scheduler, task parameter validation (including ensuring iterations > 0 and enforcing minimum execution intervals) is performed in the Magic program (on-chain) before ScheduleTaskRequest instances reach the scheduler service. The From<&ScheduleTaskRequest> conversion in db.rs does not need additional validation because inputs are already validated at the program level.
Applied to files:
magicblock-task-scheduler/Cargo.tomlmagicblock-task-scheduler/src/errors.rsmagicblock-api/src/magic_validator.rsmagicblock-task-scheduler/src/service.rsmagicblock-task-scheduler/src/db.rs
📚 Learning: 2025-11-07T18:19:48.996Z
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 614
File: test-integration/programs/schedulecommit/Cargo.toml:19-20
Timestamp: 2025-11-07T18:19:48.996Z
Learning: In Solana programs (crates depending on solana-program), the empty feature flags `custom-heap = []` and `custom-panic = []` are standard declarations required to avoid compiler warnings. These should not be flagged as unused features in Cargo.toml files for Solana program crates.
Applied to files:
magicblock-task-scheduler/Cargo.toml
📚 Learning: 2025-11-24T08:45:11.164Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 675
File: Cargo.toml:145-145
Timestamp: 2025-11-24T08:45:11.164Z
Learning: The reqwest dependency version 0.11 is intentionally used in the magicblock-validator project to maintain compatibility with the Solana client dependencies.
Applied to files:
magicblock-task-scheduler/Cargo.toml
📚 Learning: 2025-10-28T13:15:42.706Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 596
File: magicblock-processor/src/scheduler.rs:1-1
Timestamp: 2025-10-28T13:15:42.706Z
Learning: In magicblock-processor, transaction indexes were always set to 0 even before the changes in PR #596. The proper transaction indexing within slots will be addressed during the planned ledger rewrite.
Applied to files:
magicblock-task-scheduler/Cargo.toml
📚 Learning: 2025-10-21T14:00:54.642Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 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-task-scheduler/Cargo.tomlmagicblock-config/src/types/network.rstest-integration/programs/schedulecommit/src/api.rsmagicblock-task-scheduler/src/service.rs
📚 Learning: 2025-10-21T13:06:38.900Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 578
File: magicblock-aperture/src/requests/http/get_program_accounts.rs:17-25
Timestamp: 2025-10-21T13:06:38.900Z
Learning: The magicblock validator does not support ledger forking, so commitment-based state queries (processed/confirmed/finalized) are not applicable. RPC methods can safely ignore commitment and minContextSlot parameters from Solana RPC config objects.
Applied to files:
magicblock-task-scheduler/Cargo.toml
📚 Learning: 2025-10-26T16:54:39.084Z
Learnt from: thlorenz
Repo: magicblock-labs/magicblock-validator PR: 587
File: test-manual/Cargo.toml:0-0
Timestamp: 2025-10-26T16:54:39.084Z
Learning: In the magicblock-validator repository, use git branch references (not commit hashes or tags) for the helius-laserstream dependency to allow automatic updates when the branch is pushed to.
Applied to files:
magicblock-task-scheduler/Cargo.toml
📚 Learning: 2025-11-21T11:03:26.756Z
Learnt from: thlorenz
Repo: magicblock-labs/magicblock-validator PR: 664
File: magicblock-chainlink/src/testing/mod.rs:342-370
Timestamp: 2025-11-21T11:03:26.756Z
Learning: In the magicblock-validator codebase, avoid leaving review comments that merely acknowledge code is correct or well-structured when there is no actionable suggestion, improvement, or issue to flag. Only comment when there is something specific to recommend, fix, or clarify.
Applied to files:
magicblock-task-scheduler/Cargo.toml
📚 Learning: 2025-12-03T09:33:48.707Z
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 639
File: test-integration/test-committor-service/tests/test_ix_commit_local.rs:867-881
Timestamp: 2025-12-03T09:33:48.707Z
Learning: Repo: magicblock-labs/magicblock-validator PR: 639
Context: test-integration/test-committor-service/tests/test_ix_commit_local.rs (ix_commit_local)
Learning: The PhotonIndexer used for compressed account fetches (get_compressed_account) has built‑in retry logic (defaults to ~10 attempts), so tests should not add separate retry loops around compressed fetches unless there’s a specific need.
Applied to files:
magicblock-task-scheduler/Cargo.tomltest-integration/programs/schedulecommit/src/api.rsmagicblock-task-scheduler/src/service.rs
📚 Learning: 2025-11-20T08:57:07.217Z
Learnt from: thlorenz
Repo: magicblock-labs/magicblock-validator PR: 650
File: magicblock-chainlink/src/submux/subscription_task.rs:13-99
Timestamp: 2025-11-20T08:57:07.217Z
Learning: In the magicblock-validator repository, avoid posting review comments that merely confirm code is correct or matches intended behavior without providing actionable feedback, suggestions for improvement, or identifying potential issues. Such confirmatory comments are considered unhelpful noise by the maintainers.
Applied to files:
magicblock-task-scheduler/Cargo.toml
📚 Learning: 2025-11-04T13:22:38.811Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: magicblock-aperture/src/requests/http/get_fee_for_message.rs:25-31
Timestamp: 2025-11-04T13:22:38.811Z
Learning: In magicblock-aperture, request size validation (including limits on message size) is enforced at the request ingestion layer, before handlers like get_fee_for_message are invoked. Therefore, handlers do not need additional size guards on decoded data.
Applied to files:
magicblock-task-scheduler/Cargo.toml
📚 Learning: 2025-12-03T09:36:01.527Z
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 639
File: magicblock-chainlink/src/remote_account_provider/mod.rs:1350-1353
Timestamp: 2025-12-03T09:36:01.527Z
Learning: Repo: magicblock-labs/magicblock-validator
File: magicblock-chainlink/src/remote_account_provider/mod.rs
Context: consolidate_fetched_remote_accounts
Learning: For unexpected result counts (>2), the project prefers logging an error and returning an empty Vec over panicking; acceptable during development per maintainer (Dodecahedr0x).
Applied to files:
magicblock-config/src/types/network.rsmagicblock-task-scheduler/src/service.rs
📚 Learning: 2025-11-07T14:20:31.457Z
Learnt from: thlorenz
Repo: magicblock-labs/magicblock-validator PR: 621
File: magicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rs:457-495
Timestamp: 2025-11-07T14:20:31.457Z
Learning: In magicblock-chainlink/src/remote_account_provider/chain_pubsub_client.rs, the unsubscribe closure returned by PubSubConnection::account_subscribe(...) resolves to () (unit), not a Result. Downstream code should not attempt to inspect an unsubscribe result and can optionally wrap it in a timeout to guard against hangs.
Applied to files:
magicblock-config/src/types/network.rsmagicblock-task-scheduler/src/errors.rsmagicblock-task-scheduler/src/service.rs
📚 Learning: 2025-11-04T10:53:50.922Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: magicblock-processor/src/scheduler/locks.rs:110-122
Timestamp: 2025-11-04T10:53:50.922Z
Learning: In magicblock-processor, the TransactionScheduler runs in a single, dedicated thread and will always remain single-threaded. The `next_transaction_id()` function in scheduler/locks.rs uses `unsafe static mut` which is safe given this architectural guarantee.
Applied to files:
magicblock-api/src/magic_validator.rsmagicblock-task-scheduler/src/service.rsmagicblock-task-scheduler/src/db.rs
📚 Learning: 2025-11-20T17:25:23.444Z
Learnt from: JMirval
Repo: magicblock-labs/magicblock-validator PR: 656
File: programs/guinea/src/lib.rs:33-33
Timestamp: 2025-11-20T17:25:23.444Z
Learning: In the magicblock-validator codebase, task IDs (task_id) are i64 values that can be negative. The task scheduler is designed to handle any i64 value including negative task IDs. Task IDs are randomly generated using rand::random() which produces values across the full i64 range. No validation is needed to restrict task IDs to positive values.
Applied to files:
magicblock-api/src/magic_validator.rsmagicblock-task-scheduler/src/service.rsmagicblock-task-scheduler/src/db.rs
📚 Learning: 2025-11-07T13:09:52.253Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: test-kit/src/lib.rs:275-0
Timestamp: 2025-11-07T13:09:52.253Z
Learning: In test-kit, the transaction scheduler in ExecutionTestEnv is not expected to shut down during tests. Therefore, using `.unwrap()` in test helper methods like `schedule_transaction` is acceptable and will not cause issues in the test environment.
Applied to files:
magicblock-api/src/magic_validator.rsmagicblock-task-scheduler/src/service.rsmagicblock-task-scheduler/src/db.rs
📚 Learning: 2025-11-13T09:38:43.804Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: magicblock-processor/src/scheduler/locks.rs:64-102
Timestamp: 2025-11-13T09:38:43.804Z
Learning: In magicblock-processor's TransactionScheduler (scheduler/mod.rs line 59), the executor count is clamped to MAX_SVM_EXECUTORS (63) at initialization time, and executor IDs are assigned sequentially from 0 to count-1. This architectural guarantee ensures that executor IDs used in the bitmask-based AccountLock (scheduler/locks.rs) will always be within valid bounds for bit shifting operations, making runtime bounds checks unnecessary.
Applied to files:
magicblock-api/src/magic_validator.rsmagicblock-task-scheduler/src/service.rs
📚 Learning: 2025-11-21T10:22:07.520Z
Learnt from: taco-paco
Repo: magicblock-labs/magicblock-validator PR: 661
File: magicblock-committor-service/src/intent_executor/single_stage_executor.rs:20-28
Timestamp: 2025-11-21T10:22:07.520Z
Learning: In magicblock-committor-service's SingleStageExecutor and TwoStageExecutor (single_stage_executor.rs and two_stage_executor.rs), the fields transaction_strategy, junk, and patched_errors are intentionally public because these executors are designed to be used independently outside of the IntentExecutor scope, and callers need access to these execution reports for cleanup and error handling.
Applied to files:
magicblock-task-scheduler/src/service.rs
🧬 Code graph analysis (3)
magicblock-task-scheduler/src/errors.rs (3)
magicblock-committor-service/src/transaction_preparator/delivery_preparator.rs (3)
from(499-501)from(534-538)from(560-562)magicblock-api/src/errors.rs (6)
from(104-106)from(110-112)from(116-118)from(122-124)from(130-134)from(138-140)magicblock-chainlink/src/remote_account_provider/errors.rs (1)
from(95-97)
magicblock-task-scheduler/src/service.rs (1)
magicblock-core/src/link.rs (1)
link(60-89)
magicblock-task-scheduler/src/db.rs (1)
magicblock-task-scheduler/src/service.rs (1)
new(64-97)
🔇 Additional comments (1)
magicblock-task-scheduler/src/db.rs (1)
68-85: Addingcreated_at/updated_atwithout migration will break existing scheduler databasesThe
taskstable now includescreated_atandupdated_atasINTEGER NOT NULL, andinsert_taskunconditionally inserts into these columns. However,CREATE TABLE IF NOT EXISTSdoes not alter an existing table, so any pre-existingtask_scheduler.sqlitecreated before this change will not have those columns. On upgrade,INSERT OR REPLACE INTO tasks (...)will fail with "no such column: created_at/updated_at", breaking task scheduling (and possibly validator startup).You'll need either:
- a schema migration path (e.g., detect missing columns and
ALTER TABLEto add them with sensible defaults), or- a deliberate reset strategy (e.g., force
config.task_scheduler.reset = truefor this release and clearly document that tasks DB will be wiped).Right now this is a silent migration hazard.
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
magicblock-task-scheduler/src/service.rs (2)
194-223: Consider retry logic for transient RPC failures.The current implementation removes and logs failed tasks (lines 270-271), which is reasonable. However, for improved resilience, consider distinguishing between transient network errors (which could be retried) versus permanent failures (invalid transaction). This could be implemented by:
- Inspecting the error type from
send_transaction- Implementing a bounded retry with backoff for retriable errors
- Only marking the task as failed after retry exhaustion
This is optional and depends on the reliability requirements for scheduled tasks.
57-62: Update the safety comment to reflect the actual struct fields and verify necessity of unsafe impls.The safety comment lists
TransactionSchedulerHandle(line 58) which is not a field in the struct, and omitsRpcClientwhich is. Update the comment to accurately list:SchedulerDatabase, RpcClient, ScheduledTasksRx, LatestBlock, DelayQueue, HashMap, AtomicU64, CancellationToken. If all these fields are confirmed to beSend+Sync, consider whether the unsafe impls can be removed and let the compiler auto-derive these traits, or document the specific reason they remain necessary.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
magicblock-task-scheduler/src/service.rs(8 hunks)
🧰 Additional context used
🧠 Learnings (16)
📓 Common learnings
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 614
File: magicblock-task-scheduler/src/db.rs:26-0
Timestamp: 2025-11-12T09:46:27.553Z
Learning: In magicblock-task-scheduler, task parameter validation (including ensuring iterations > 0 and enforcing minimum execution intervals) is performed in the Magic program (on-chain) before ScheduleTaskRequest instances reach the scheduler service. The From<&ScheduleTaskRequest> conversion in db.rs does not need additional validation because inputs are already validated at the program level.
📚 Learning: 2025-11-04T10:53:50.922Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: magicblock-processor/src/scheduler/locks.rs:110-122
Timestamp: 2025-11-04T10:53:50.922Z
Learning: In magicblock-processor, the TransactionScheduler runs in a single, dedicated thread and will always remain single-threaded. The `next_transaction_id()` function in scheduler/locks.rs uses `unsafe static mut` which is safe given this architectural guarantee.
Applied to files:
magicblock-task-scheduler/src/service.rs
📚 Learning: 2025-11-12T09:46:27.553Z
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 614
File: magicblock-task-scheduler/src/db.rs:26-0
Timestamp: 2025-11-12T09:46:27.553Z
Learning: In magicblock-task-scheduler, task parameter validation (including ensuring iterations > 0 and enforcing minimum execution intervals) is performed in the Magic program (on-chain) before ScheduleTaskRequest instances reach the scheduler service. The From<&ScheduleTaskRequest> conversion in db.rs does not need additional validation because inputs are already validated at the program level.
Applied to files:
magicblock-task-scheduler/src/service.rs
📚 Learning: 2025-10-21T14:00:54.642Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 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-task-scheduler/src/service.rs
📚 Learning: 2025-12-03T09:33:48.707Z
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 639
File: test-integration/test-committor-service/tests/test_ix_commit_local.rs:867-881
Timestamp: 2025-12-03T09:33:48.707Z
Learning: Repo: magicblock-labs/magicblock-validator PR: 639
Context: test-integration/test-committor-service/tests/test_ix_commit_local.rs (ix_commit_local)
Learning: The PhotonIndexer used for compressed account fetches (get_compressed_account) has built‑in retry logic (defaults to ~10 attempts), so tests should not add separate retry loops around compressed fetches unless there’s a specific need.
Applied to files:
magicblock-task-scheduler/src/service.rs
📚 Learning: 2025-11-07T14:20:31.457Z
Learnt from: thlorenz
Repo: magicblock-labs/magicblock-validator PR: 621
File: magicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rs:457-495
Timestamp: 2025-11-07T14:20:31.457Z
Learning: In magicblock-chainlink/src/remote_account_provider/chain_pubsub_client.rs, the unsubscribe closure returned by PubSubConnection::account_subscribe(...) resolves to () (unit), not a Result. Downstream code should not attempt to inspect an unsubscribe result and can optionally wrap it in a timeout to guard against hangs.
Applied to files:
magicblock-task-scheduler/src/service.rs
📚 Learning: 2025-12-03T09:36:01.527Z
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 639
File: magicblock-chainlink/src/remote_account_provider/mod.rs:1350-1353
Timestamp: 2025-12-03T09:36:01.527Z
Learning: Repo: magicblock-labs/magicblock-validator
File: magicblock-chainlink/src/remote_account_provider/mod.rs
Context: consolidate_fetched_remote_accounts
Learning: For unexpected result counts (>2), the project prefers logging an error and returning an empty Vec over panicking; acceptable during development per maintainer (Dodecahedr0x).
Applied to files:
magicblock-task-scheduler/src/service.rs
📚 Learning: 2025-11-19T09:34:37.917Z
Learnt from: thlorenz
Repo: magicblock-labs/magicblock-validator PR: 621
File: test-integration/test-chainlink/tests/ix_remote_account_provider.rs:62-63
Timestamp: 2025-11-19T09:34:37.917Z
Learning: In test-integration/test-chainlink/tests/ix_remote_account_provider.rs and similar test files, the `_fwd_rx` receiver returned by `init_remote_account_provider()` is intentionally kept alive (but unused) to prevent "receiver dropped" errors on the sender side. The pattern `let (remote_account_provider, _fwd_rx) = init_remote_account_provider().await;` should NOT be changed to `let (remote_account_provider, _) = ...` because dropping the receiver would cause send() operations to fail.
Applied to files:
magicblock-task-scheduler/src/service.rs
📚 Learning: 2025-11-07T13:09:52.253Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: test-kit/src/lib.rs:275-0
Timestamp: 2025-11-07T13:09:52.253Z
Learning: In test-kit, the transaction scheduler in ExecutionTestEnv is not expected to shut down during tests. Therefore, using `.unwrap()` in test helper methods like `schedule_transaction` is acceptable and will not cause issues in the test environment.
Applied to files:
magicblock-task-scheduler/src/service.rs
📚 Learning: 2025-12-01T16:02:05.367Z
Learnt from: thlorenz
Repo: magicblock-labs/magicblock-validator PR: 703
File: magicblock-chainlink/src/submux/mod.rs:652-654
Timestamp: 2025-12-01T16:02:05.367Z
Learning: In magicblock-chainlink/src/submux/mod.rs, the subscribe_program method intentionally adds program_id to program_subs before attempting the subscription. This ensures that even if the initial subscription fails or only partially succeeds across clients, the reconnection logic will retry the subscription. This is a deliberate design pattern for resilience in the multi-client architecture and should not be "fixed" to remove entries on failure.
Applied to files:
magicblock-task-scheduler/src/service.rs
📚 Learning: 2025-10-28T13:15:42.706Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 596
File: magicblock-processor/src/scheduler.rs:1-1
Timestamp: 2025-10-28T13:15:42.706Z
Learning: In magicblock-processor, transaction indexes were always set to 0 even before the changes in PR #596. The proper transaction indexing within slots will be addressed during the planned ledger rewrite.
Applied to files:
magicblock-task-scheduler/src/service.rs
📚 Learning: 2025-11-21T10:22:07.520Z
Learnt from: taco-paco
Repo: magicblock-labs/magicblock-validator PR: 661
File: magicblock-committor-service/src/intent_executor/single_stage_executor.rs:20-28
Timestamp: 2025-11-21T10:22:07.520Z
Learning: In magicblock-committor-service's SingleStageExecutor and TwoStageExecutor (single_stage_executor.rs and two_stage_executor.rs), the fields transaction_strategy, junk, and patched_errors are intentionally public because these executors are designed to be used independently outside of the IntentExecutor scope, and callers need access to these execution reports for cleanup and error handling.
Applied to files:
magicblock-task-scheduler/src/service.rs
📚 Learning: 2025-11-20T08:57:07.217Z
Learnt from: thlorenz
Repo: magicblock-labs/magicblock-validator PR: 650
File: magicblock-chainlink/src/submux/subscription_task.rs:13-99
Timestamp: 2025-11-20T08:57:07.217Z
Learning: In the magicblock-validator repository, avoid posting review comments that merely confirm code is correct or matches intended behavior without providing actionable feedback, suggestions for improvement, or identifying potential issues. Such confirmatory comments are considered unhelpful noise by the maintainers.
Applied to files:
magicblock-task-scheduler/src/service.rs
📚 Learning: 2025-11-21T11:03:26.756Z
Learnt from: thlorenz
Repo: magicblock-labs/magicblock-validator PR: 664
File: magicblock-chainlink/src/testing/mod.rs:342-370
Timestamp: 2025-11-21T11:03:26.756Z
Learning: In the magicblock-validator codebase, avoid leaving review comments that merely acknowledge code is correct or well-structured when there is no actionable suggestion, improvement, or issue to flag. Only comment when there is something specific to recommend, fix, or clarify.
Applied to files:
magicblock-task-scheduler/src/service.rs
📚 Learning: 2025-11-13T09:38:43.804Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: magicblock-processor/src/scheduler/locks.rs:64-102
Timestamp: 2025-11-13T09:38:43.804Z
Learning: In magicblock-processor's TransactionScheduler (scheduler/mod.rs line 59), the executor count is clamped to MAX_SVM_EXECUTORS (63) at initialization time, and executor IDs are assigned sequentially from 0 to count-1. This architectural guarantee ensures that executor IDs used in the bitmask-based AccountLock (scheduler/locks.rs) will always be within valid bounds for bit shifting operations, making runtime bounds checks unnecessary.
Applied to files:
magicblock-task-scheduler/src/service.rs
📚 Learning: 2025-11-20T17:25:23.444Z
Learnt from: JMirval
Repo: magicblock-labs/magicblock-validator PR: 656
File: programs/guinea/src/lib.rs:33-33
Timestamp: 2025-11-20T17:25:23.444Z
Learning: In the magicblock-validator codebase, task IDs (task_id) are i64 values that can be negative. The task scheduler is designed to handle any i64 value including negative task IDs. Task IDs are randomly generated using rand::random() which produces values across the full i64 range. No validation is needed to restrict task IDs to positive values.
Applied to files:
magicblock-task-scheduler/src/service.rs
🧬 Code graph analysis (1)
magicblock-task-scheduler/src/service.rs (1)
magicblock-core/src/link.rs (1)
link(60-89)
🔇 Additional comments (4)
magicblock-task-scheduler/src/service.rs (4)
17-21: LGTM!Import changes correctly switch to granular Solana crates and use the nonblocking
RpcClientfor async transaction submission.
36-37: LGTM!Field replacement and error boxing changes align with the PR objective to route transactions through RPC for proper Chainlink integration.
Also applies to: 54-54
141-141: LGTM!Error boxing is consistent in both branches and matches the updated
ProcessingOutcome::Recoverable(Box<TaskSchedulerError>)signature.Also applies to: 159-159
323-327: LGTM!The implementation correctly uses the signature returned by
send_transactionand properly boxes the error for conversion.
Dodecahedr0x
force-pushed
the
dode/schedule-with-rpc
branch
from
d0f7dec to
f4cd087
Compare
Co-authored-by: Thorsten Lorenz <thlorenz@gmx.de> Co-authored-by: Dodecahedr0x <hexadecifish@gmail.com> Co-authored-by: taco-paco <edwinswatpako@gmail.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 10
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
magicblock-ledger/src/store/api.rs (1)
1268-1276: Explicitflush()call removed from shutdown without compensating at higher level.The ledger's
shutdown()method no longer explicitly flushes data before callingcancel_all_background_work(wait). While the higher-level shutdown sequence inmagic_validator.rsflushesaccountsdb, the ledger itself is not flushed. RocksDB'scancel_all_background_work(wait=true)waits for background operations (compaction, etc.) to complete but does not guarantee flushing of memtables to disk. This risks data loss if shutdown is interrupted or incomplete. Callself.flush()?beforecancel_all_background_work(wait)in the shutdown method to ensure durability.
♻️ Duplicate comments (2)
magicblock-api/src/magic_validator.rs (1)
295-305: LGTM! TaskSchedulerService initialization updated.The constructor now correctly receives
config.listen.http()for RPC URL, addressing the previous review feedback about exposing internal details.magicblock-task-scheduler/src/service.rs (1)
87-89: Consider explicit timeout configuration for production resilience.
RpcClient::new(rpc_url)uses the default 30-second timeout. For production environments with varying network conditions, consider usingRpcClient::new_with_timeout(rpc_url, timeout)to allow configurable timeout values.
🧹 Nitpick comments (17)
magicblock-committor-program/src/state/chunks.rs (1)
18-20: Consider using the actual constant name for consistency.The doc example uses
BIT_FIELD_SIZEwhile the implementation usesBITS_PER_BYTE(line 7). Using the same name would help readers connect the example to the actual code.🔎 Suggested change
/// ```rust - /// # const BIT_FIELD_SIZE: usize = 8; + /// # const BITS_PER_BYTE: usize = 8; /// # let bits = vec![0u8; 1]; - /// let capacity = bits.len() * BIT_FIELD_SIZE; + /// let capacity = bits.len() * BITS_PER_BYTE; /// ```magicblock-aperture/src/server/websocket/connection.rs (1)
105-111: Correct the misleading comment about close frame handling.The comment on line 108 states "without close frame," but a close frame is actually sent after the loop exits (lines 178-181). The comment should be updated to reflect the actual behavior.
🔎 Suggested fix
// Prioritize fast system shutdown biased; - // 0. We force shutdown the connection, without close frame + // 0. Force shutdown on cancellation signal (close frame sent after loop exit) _ = self.cancel.cancelled() => break, -README.md (2)
74-74: Clarify remote cluster configuration.The example shows both HTTP and WSS URLs. Add guidance on when each URL type is used (e.g., HTTP for RPC calls, WSS for subscriptions).
🔎 Proposed enhancement
-# Example: Sync with Solana Devnet -remotes = ["https://api.devnet.solana.com", "wss://api.devnet.solana.com"] +# Example: Sync with Solana Devnet +# Note: HTTP URLs are used for RPC calls, WSS URLs for subscriptions +remotes = ["https://api.devnet.solana.com", "wss://api.devnet.solana.com"]
105-105: Specify Docker image version tag.The Docker command uses an implicit 'latest' tag, which is not recommended for production deployments. Specify an explicit version.
🔎 Proposed improvement
-docker run -p 8899:8899 -p 8900:8900 magicblocklabs/validator +docker run -p 8899:8899 -p 8900:8900 magicblocklabs/validator:latestOr use a specific release version:
docker run -p 8899:8899 -p 8900:8900 magicblocklabs/validator:v0.1.0magicblock-aperture/src/requests/http/get_blocks_with_limit.rs (1)
23-24: Off-by-one fix correctly includes the latest block.The change from
block_height()toblock_height() + 1fixes an off-by-one error. Previously, the exclusive range(start_slot..end_slot)would exclude the block atblock_height(), preventing users from retrieving the latest block. The new logic correctly allows the latest block to be included in results.Consider updating the comment at line 23 to clarify the inclusive behavior:
- // Calculate the end slot, ensuring it does not exceed the latest block height. + // Calculate the end slot, allowing up to and including the latest block height.docs/GOVERNANCE.md (2)
48-48: Use standard capitalization for GitHub references.The file path
.github/CODEOWNERSis correct (lowercase directory). If the document refers to "GitHub" as the platform/service name elsewhere, ensure it uses the standard capitalization "GitHub".
95-95: Remove redundancy: "consult with" → "consult".The phrasing can be simplified for conciseness without loss of clarity.
🔎 Proposed fix
- Before implementing significant changes, the assignee must consult with the CO of the affected crate(s) to align on the proposed design and impact. + Before implementing significant changes, the assignee must consult the CO of the affected crate(s) to align on the proposed design and impact..github/ISSUE_TEMPLATE/feature.yml (1)
1-16: LGTM!The feature request template provides clear structure with Problem/Proposal/Acceptance criteria sections. The concise format encourages focused feature discussions.
Optional: Consider adding supplementary fields
You might consider adding optional fields for richer context, such as:
validations: required: true + + - type: textarea + id: alternatives + attributes: + label: Alternatives Considered + description: Other approaches you've considered (optional). + placeholder: "Alternative solutions..." + validations: + required: false + + - type: textarea + id: context + attributes: + label: Additional Context + description: Use cases, screenshots, examples, etc. (optional). + placeholder: "Context..." + validations: + required: falseThis is entirely optional—the current template is already effective.
.coderabbit.yaml (1)
34-44: Consider keeping some pre-merge checks in warning mode.All pre-merge checks are now disabled (
mode: off), which removes automated quality gates. While this aligns with the stated goal of keeping friction low, completely disabling these checks means:
- No automated reminders about missing docstrings
- No automated validation of PR titles/descriptions
- No assessment of whether changes address linked issues
If the goal is to reduce blocking friction while maintaining visibility, consider setting these to
mode: warninginstead ofoff. Warning mode provides feedback without blocking merges.Alternative: Use warning mode for non-blocking feedback
pre_merge_checks: docstrings: - mode: off + mode: warning title: - mode: off + mode: warning description: - mode: off + mode: warning issue_assessment: - mode: off + mode: warningmagicblock-processor/src/scheduler/locks.rs (1)
62-63: Minor: Fix typos in doc comments."exeucotor" → "executor"
🔎 Proposed fix
- /// The return Err value corresponds to the exeucotor ID, holding the lock + /// The return Err value corresponds to the executor ID holding the lock- /// The return Err value corresponds to the exeucotor ID, holding the lock + /// The return Err value corresponds to the executor ID holding the lockAlso applies to: 79-79
magicblock-chainlink/src/remote_account_provider/mod.rs (1)
1054-1064: Consider using theretry!macro for consistency.The timeout handler duplicates retry logic (decrement, check, sleep, continue) that's already encapsulated in the
retry!macro. Consider using the macro for consistency and to avoid potential maintenance drift.🔎 Proposed fix
Err(_) => { - warn!("RPC call timeout. Retrying..."); - remaining_retries -= 1; - if remaining_retries == 0 { - let err_msg = format!("Max retries {MAX_RETRIES} reached, giving up on fetching accounts: {pubkeys:?}"); - notify_error(&err_msg); - return; - } - tokio::time::sleep(Duration::from_millis(400)).await; - continue; + retry!("RPC call timeout. Retrying..."); }config.example.toml (1)
34-58: LGTM! Comprehensive documentation for remotes configuration.The migration from
remotetoremotesis well-documented with clear examples and explanation of supported URL schemes and aliases. The documentation effectively guides users through the new multi-remote configuration.However, consider clarifying that gRPC URLs do not support aliases (mainnet/devnet/testnet/localhost) and must use explicit URLs. Based on learnings, the
resolve_urlfunction passes gRPC URLs through as-is without alias resolution.🔎 Suggested documentation enhancement
# URL Aliases (resolved during parsing): -# - "mainnet": resolves to https://api.mainnet-beta.solana.com/ -# - "devnet": resolves to https://api.devnet.solana.com/ -# - "testnet": resolves to https://api.testnet.solana.com/ -# - "localhost": resolves to http://localhost:8899/ (only for http/https schemes) +# - "mainnet": resolves to https://api.mainnet-beta.solana.com/ (HTTP/WebSocket only) +# - "devnet": resolves to https://api.devnet.solana.com/ (HTTP/WebSocket only) +# - "testnet": resolves to https://api.testnet.solana.com/ (HTTP/WebSocket only) +# - "localhost": resolves to http://localhost:8899/ (HTTP/WebSocket only) +# Note: gRPC URLs do not support aliases and must be specified explicitly.magicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rs (1)
606-627: LGTM with minor optimization opportunity.The update handling logic correctly:
- Parses the account pubkey from the response
- Only forwards updates for accounts that are directly subscribed
- Tracks metrics per client
The
client_id.to_string()allocation on every update is a minor overhead. Consider caching the string representation if this becomes a hot path.🔎 Optional: Cache client_id string to avoid repeated allocations
Pre-compute the client ID string and pass it into the spawned task:
+ let client_id_str = client_id.to_string(); tokio::spawn(async move { // ... inc_program_subscription_account_updates( - &client_id.to_string(), + &client_id_str, );test-integration/test-tools/src/toml_to_args.rs (1)
25-44: Fallback returns URL without scheme when parsing fails.When
Remote::from_str(&full_url)fails on line 38, the fallback on line 42 returnsself.url.clone()which lacks the scheme prefix (e.g.,http://). This could cause downstream issues since the caller expects a full URL with scheme.Consider returning
full_urlinstead ofself.urlin the error case:🔎 Proposed fix
// Parse the full URL into a Remote instance to resolve aliases if let Ok(remote) = Remote::from_str(&full_url) { remote.url_str().to_string() } else { // If parsing fails, return the raw URL - self.url.clone() + full_url }magicblock-config/src/types/network.rs (2)
60-82: Consider using a more semantically appropriate error for unknown schemes.The
InvalidDomainCharactererror at line 78 is returned for unsupported URL schemes, but this is semantically misleading since the actual issue is an unrecognized scheme, not an invalid domain character. Unfortunately,url::ParseErrordoesn't have anInvalidSchemevariant.This is acceptable as-is since
url::ParseErrorhas limited variants, but consider documenting this behavior or wrapping with a custom error type in the future if more granular error handling becomes necessary.
106-109: Port increment could overflow at 65535.When
portis 65535,port + 1overflows to 0 (due to wrapping) which may produce unexpected behavior. While this is unlikely in practice (standard ports are well below this), consider adding a saturating operation or returningNonefor invalid port ranges.🔎 Proposed defensive fix
if let Some(port) = url.port() { // As per solana convention websocket port is one greater than http - let _ = url.set_port(Some(port + 1)); + let _ = url.set_port(port.checked_add(1)); }Note:
set_port(None)removes the port, which effectively uses the default port for the scheme. This is a reasonable fallback if the port would overflow.magicblock-chainlink/src/chainlink/fetch_cloner.rs (1)
1258-1273: Add observability for timeout occurrences via metrics and tests.The 5-second timeout prevents hanging on delegation record checks during account refresh decisions, which aligns with making the crank more reliable. On timeout, the code logs a warning and defaults to
RefreshDecision::No. This pattern is consistent with the codebase's established error handling approach. Since accounts marked as undelegating are checked repeatedly, any temporary staleness from a timeout is bounded and will be resolved on the next iteration.To improve observability and test coverage, consider:
- Adding a metric to track timeout occurrences (the metrics infrastructure already exists in the codebase)
- Adding a test that simulates slow delegation record fetches to verify timeout behavior is handled correctly
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (3)
Cargo.lockis excluded by!**/*.lockdocs/bank-usage.svgis excluded by!**/*.svgtest-integration/Cargo.lockis excluded by!**/*.lock
📒 Files selected for processing (97)
.coderabbit.yaml.github/ISSUE_TEMPLATE/bug.yml.github/ISSUE_TEMPLATE/config.yml.github/ISSUE_TEMPLATE/docs.yml.github/ISSUE_TEMPLATE/feature.yml.github/PULL_REQUEST_TEMPLATE.md.github/workflows/ci-fmt.ymlCargo.tomlREADME.mdconfig.example.tomldocs/CODE_OF_CONDUCT.mddocs/CONTRIBUTING.mddocs/GOVERNANCE.mddocs/SECURITY.mddocs/central-scheduler.mddocs/features.mddocs/loading-existing-ledger.mddocs/memory-issue.mddocs/rpc.mddocs/runtime.mddocs/schedule-commit-flow.mddocs/send-transaction-service.mdmagicblock-accounts/src/config.rsmagicblock-aperture/Cargo.tomlmagicblock-aperture/src/requests/http/get_blocks_with_limit.rsmagicblock-aperture/src/requests/http/get_token_account_balance.rsmagicblock-aperture/src/requests/http/mocked.rsmagicblock-aperture/src/requests/http/request_airdrop.rsmagicblock-aperture/src/server/http/mod.rsmagicblock-aperture/src/server/websocket/connection.rsmagicblock-aperture/src/server/websocket/mod.rsmagicblock-aperture/src/tests.rsmagicblock-aperture/tests/mocked.rsmagicblock-aperture/tests/node.rsmagicblock-aperture/tests/setup.rsmagicblock-api/src/magic_validator.rsmagicblock-api/src/tickers.rsmagicblock-chainlink/src/chainlink/fetch_cloner.rsmagicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rsmagicblock-chainlink/src/remote_account_provider/mod.rsmagicblock-chainlink/src/submux/mod.rsmagicblock-committor-program/src/state/chunks.rsmagicblock-committor-service/src/service.rsmagicblock-config/src/config/cli.rsmagicblock-config/src/consts.rsmagicblock-config/src/lib.rsmagicblock-config/src/tests.rsmagicblock-config/src/types/mod.rsmagicblock-config/src/types/network.rsmagicblock-core/src/link/transactions.rsmagicblock-ledger/Cargo.tomlmagicblock-ledger/src/database/columns.rsmagicblock-ledger/src/ledger_truncator.rsmagicblock-ledger/src/store/api.rsmagicblock-metrics/src/metrics/mod.rsmagicblock-metrics/src/metrics/types.rsmagicblock-metrics/src/service.rsmagicblock-processor/Cargo.tomlmagicblock-processor/src/executor/mod.rsmagicblock-processor/src/executor/processing.rsmagicblock-processor/src/lib.rsmagicblock-processor/src/scheduler.rsmagicblock-processor/src/scheduler/coordinator.rsmagicblock-processor/src/scheduler/locks.rsmagicblock-processor/src/scheduler/mod.rsmagicblock-processor/src/scheduler/tests.rsmagicblock-processor/tests/fees.rsmagicblock-processor/tests/scheduling.rsmagicblock-processor/tests/security.rsmagicblock-table-mania/src/manager.rsmagicblock-task-scheduler/README.mdmagicblock-task-scheduler/src/service.rsmagicblock-validator/src/main.rstest-integration/configs/api-conf.ephem.tomltest-integration/configs/chainlink-conf.devnet.tomltest-integration/configs/claim-fees-test.tomltest-integration/configs/cloning-conf.devnet.tomltest-integration/configs/cloning-conf.ephem.tomltest-integration/configs/committor-conf.devnet.tomltest-integration/configs/config-conf.devnet.tomltest-integration/configs/restore-ledger-conf.devnet.tomltest-integration/configs/schedule-task.devnet.tomltest-integration/configs/schedule-task.ephem.tomltest-integration/configs/schedulecommit-conf-fees.ephem.tomltest-integration/configs/schedulecommit-conf.devnet.tomltest-integration/configs/schedulecommit-conf.ephem.frequent-commits.tomltest-integration/configs/schedulecommit-conf.ephem.tomltest-integration/configs/validator-offline.devnet.tomltest-integration/test-config/src/lib.rstest-integration/test-config/tests/auto_airdrop_feepayer.rstest-integration/test-ledger-restore/src/lib.rstest-integration/test-magicblock-api/src/lib.rstest-integration/test-runner/bin/run_tests.rstest-integration/test-task-scheduler/src/lib.rstest-integration/test-tools/src/toml_to_args.rstest-integration/test-tools/src/validator.rstest-kit/src/lib.rs
💤 Files with no reviewable changes (15)
- .github/workflows/ci-fmt.yml
- docs/send-transaction-service.md
- test-integration/test-runner/bin/run_tests.rs
- docs/loading-existing-ledger.md
- magicblock-processor/src/lib.rs
- magicblock-accounts/src/config.rs
- docs/runtime.md
- docs/central-scheduler.md
- magicblock-processor/src/scheduler.rs
- test-integration/test-tools/src/validator.rs
- docs/rpc.md
- docs/schedule-commit-flow.md
- docs/memory-issue.md
- test-integration/test-magicblock-api/src/lib.rs
- docs/features.md
✅ Files skipped from review due to trivial changes (5)
- magicblock-committor-service/src/service.rs
- docs/SECURITY.md
- magicblock-task-scheduler/README.md
- .github/ISSUE_TEMPLATE/docs.yml
- .github/PULL_REQUEST_TEMPLATE.md
🧰 Additional context used
🧠 Learnings (31)
📓 Common learnings
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 614
File: magicblock-task-scheduler/src/db.rs:26-0
Timestamp: 2025-11-12T09:46:27.553Z
Learning: In magicblock-task-scheduler, task parameter validation (including ensuring iterations > 0 and enforcing minimum execution intervals) is performed in the Magic program (on-chain) before ScheduleTaskRequest instances reach the scheduler service. The From<&ScheduleTaskRequest> conversion in db.rs does not need additional validation because inputs are already validated at the program level.
📚 Learning: 2025-12-03T09:36:01.527Z
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 639
File: magicblock-chainlink/src/remote_account_provider/mod.rs:1350-1353
Timestamp: 2025-12-03T09:36:01.527Z
Learning: Repo: magicblock-labs/magicblock-validator
File: magicblock-chainlink/src/remote_account_provider/mod.rs
Context: consolidate_fetched_remote_accounts
Learning: For unexpected result counts (>2), the project prefers logging an error and returning an empty Vec over panicking; acceptable during development per maintainer (Dodecahedr0x).
Applied to files:
magicblock-aperture/src/requests/http/request_airdrop.rsmagicblock-api/src/tickers.rsmagicblock-aperture/src/requests/http/get_token_account_balance.rsmagicblock-chainlink/src/remote_account_provider/mod.rstest-integration/configs/cloning-conf.ephem.tomlmagicblock-chainlink/src/chainlink/fetch_cloner.rsmagicblock-processor/src/executor/processing.rsmagicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rsmagicblock-processor/tests/scheduling.rstest-integration/test-config/tests/auto_airdrop_feepayer.rsmagicblock-config/src/config/cli.rstest-integration/test-config/src/lib.rsmagicblock-metrics/src/metrics/mod.rsmagicblock-config/src/lib.rsmagicblock-chainlink/src/submux/mod.rsmagicblock-task-scheduler/src/service.rstest-integration/test-task-scheduler/src/lib.rsmagicblock-aperture/tests/mocked.rsmagicblock-api/src/magic_validator.rsmagicblock-config/src/types/network.rstest-integration/test-tools/src/toml_to_args.rsmagicblock-config/src/consts.rsmagicblock-config/src/tests.rstest-integration/test-ledger-restore/src/lib.rsmagicblock-processor/tests/fees.rs
📚 Learning: 2025-12-03T09:33:48.707Z
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 639
File: test-integration/test-committor-service/tests/test_ix_commit_local.rs:867-881
Timestamp: 2025-12-03T09:33:48.707Z
Learning: Repo: magicblock-labs/magicblock-validator PR: 639
Context: test-integration/test-committor-service/tests/test_ix_commit_local.rs (ix_commit_local)
Learning: The PhotonIndexer used for compressed account fetches (get_compressed_account) has built‑in retry logic (defaults to ~10 attempts), so tests should not add separate retry loops around compressed fetches unless there’s a specific need.
Applied to files:
magicblock-aperture/src/requests/http/request_airdrop.rsmagicblock-aperture/src/tests.rsmagicblock-chainlink/src/remote_account_provider/mod.rsmagicblock-chainlink/src/chainlink/fetch_cloner.rsmagicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rsmagicblock-processor/tests/scheduling.rstest-integration/test-config/tests/auto_airdrop_feepayer.rsmagicblock-processor/src/scheduler/tests.rsmagicblock-aperture/tests/setup.rsmagicblock-task-scheduler/src/service.rsmagicblock-aperture/tests/mocked.rsmagicblock-api/src/magic_validator.rsmagicblock-aperture/tests/node.rsmagicblock-processor/tests/fees.rsCargo.toml
📚 Learning: 2025-11-24T14:21:00.996Z
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 639
File: Cargo.toml:58-58
Timestamp: 2025-11-24T14:21:00.996Z
Learning: In the magicblock-validator codebase, magicblock-api/Cargo.toml intentionally uses borsh = "1.5.3" (instead of the workspace version 0.10.4) because it needs to deserialize types from the magic-domain-program external dependency, which requires borsh 1.5.x compatibility. This is an intentional exception for interoperability with the magic domain program.
Applied to files:
magicblock-processor/Cargo.tomlmagicblock-ledger/Cargo.tomlmagicblock-aperture/Cargo.tomlmagicblock-config/src/types/mod.rsCargo.toml
📚 Learning: 2025-11-07T18:19:48.996Z
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 614
File: test-integration/programs/schedulecommit/Cargo.toml:19-20
Timestamp: 2025-11-07T18:19:48.996Z
Learning: In Solana programs (crates depending on solana-program), the empty feature flags `custom-heap = []` and `custom-panic = []` are standard declarations required to avoid compiler warnings. These should not be flagged as unused features in Cargo.toml files for Solana program crates.
Applied to files:
magicblock-processor/Cargo.tomlmagicblock-ledger/Cargo.tomlCargo.toml
📚 Learning: 2025-11-21T10:22:07.520Z
Learnt from: taco-paco
Repo: magicblock-labs/magicblock-validator PR: 661
File: magicblock-committor-service/src/intent_executor/single_stage_executor.rs:20-28
Timestamp: 2025-11-21T10:22:07.520Z
Learning: In magicblock-committor-service's SingleStageExecutor and TwoStageExecutor (single_stage_executor.rs and two_stage_executor.rs), the fields transaction_strategy, junk, and patched_errors are intentionally public because these executors are designed to be used independently outside of the IntentExecutor scope, and callers need access to these execution reports for cleanup and error handling.
Applied to files:
magicblock-core/src/link/transactions.rsmagicblock-processor/src/executor/processing.rsmagicblock-processor/src/executor/mod.rsmagicblock-processor/tests/scheduling.rsmagicblock-processor/src/scheduler/tests.rsmagicblock-processor/src/scheduler/mod.rsmagicblock-task-scheduler/src/service.rsmagicblock-processor/src/scheduler/locks.rsmagicblock-api/src/magic_validator.rstest-kit/src/lib.rsmagicblock-processor/src/scheduler/coordinator.rs
📚 Learning: 2025-10-21T11:00:18.396Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 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/requests/http/get_blocks_with_limit.rs
📚 Learning: 2025-11-19T09:34:37.917Z
Learnt from: thlorenz
Repo: magicblock-labs/magicblock-validator PR: 621
File: test-integration/test-chainlink/tests/ix_remote_account_provider.rs:62-63
Timestamp: 2025-11-19T09:34:37.917Z
Learning: In test-integration/test-chainlink/tests/ix_remote_account_provider.rs and similar test files, the `_fwd_rx` receiver returned by `init_remote_account_provider()` is intentionally kept alive (but unused) to prevent "receiver dropped" errors on the sender side. The pattern `let (remote_account_provider, _fwd_rx) = init_remote_account_provider().await;` should NOT be changed to `let (remote_account_provider, _) = ...` because dropping the receiver would cause send() operations to fail.
Applied to files:
magicblock-chainlink/src/remote_account_provider/mod.rsmagicblock-chainlink/src/chainlink/fetch_cloner.rsmagicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rstest-integration/test-config/tests/auto_airdrop_feepayer.rsmagicblock-processor/src/scheduler/tests.rsmagicblock-aperture/tests/setup.rsmagicblock-processor/src/scheduler/mod.rstest-integration/test-config/src/lib.rsmagicblock-task-scheduler/src/service.rsmagicblock-processor/tests/security.rsmagicblock-aperture/tests/mocked.rsmagicblock-config/src/tests.rstest-integration/test-ledger-restore/src/lib.rsmagicblock-processor/tests/fees.rs
📚 Learning: 2025-11-07T14:20:31.457Z
Learnt from: thlorenz
Repo: magicblock-labs/magicblock-validator PR: 621
File: magicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rs:457-495
Timestamp: 2025-11-07T14:20:31.457Z
Learning: In magicblock-chainlink/src/remote_account_provider/chain_pubsub_client.rs, the unsubscribe closure returned by PubSubConnection::account_subscribe(...) resolves to () (unit), not a Result. Downstream code should not attempt to inspect an unsubscribe result and can optionally wrap it in a timeout to guard against hangs.
Applied to files:
magicblock-chainlink/src/remote_account_provider/mod.rsmagicblock-chainlink/src/chainlink/fetch_cloner.rsmagicblock-aperture/src/server/websocket/connection.rsmagicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rsmagicblock-chainlink/src/submux/mod.rsmagicblock-task-scheduler/src/service.rsmagicblock-api/src/magic_validator.rsmagicblock-config/src/types/network.rs
📚 Learning: 2025-11-18T08:47:39.702Z
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 639
File: magicblock-chainlink/tests/04_redeleg_other_separate_slots.rs:158-165
Timestamp: 2025-11-18T08:47:39.702Z
Learning: In magicblock-chainlink tests involving compressed accounts, `set_remote_slot()` sets the slot of the `AccountSharedData`, while `compressed_account_shared_with_owner_and_slot()` sets the slot of the delegation record. These are two different fields and both calls are necessary.
Applied to files:
magicblock-chainlink/src/remote_account_provider/mod.rs
📚 Learning: 2025-10-21T14:00:54.642Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 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-chainlink/src/remote_account_provider/mod.rsmagicblock-aperture/src/requests/http/mocked.rsmagicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rsmagicblock-metrics/src/metrics/mod.rsmagicblock-chainlink/src/submux/mod.rsmagicblock-task-scheduler/src/service.rsmagicblock-api/src/magic_validator.rsmagicblock-config/src/types/network.rsCargo.toml
📚 Learning: 2025-11-24T08:45:11.164Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 675
File: Cargo.toml:145-145
Timestamp: 2025-11-24T08:45:11.164Z
Learning: The reqwest dependency version 0.11 is intentionally used in the magicblock-validator project to maintain compatibility with the Solana client dependencies.
Applied to files:
magicblock-aperture/Cargo.tomlCargo.toml
📚 Learning: 2025-12-15T20:32:57.435Z
Learnt from: thlorenz
Repo: magicblock-labs/magicblock-validator PR: 746
File: magicblock-config/src/tests.rs:680-703
Timestamp: 2025-12-15T20:32:57.435Z
Learning: In the magicblock-validator repository, gRPC remotes do not support URL aliases (mainnet, devnet, local) like RPC and WebSocket remotes do. The resolve_url function passes gRPC URLs through as-is without alias resolution.
Applied to files:
config.example.tomltest-integration/test-config/src/lib.rsmagicblock-config/src/lib.rsmagicblock-config/src/types/network.rstest-integration/test-tools/src/toml_to_args.rs
📚 Learning: 2025-12-17T12:46:36.207Z
Learnt from: GabrielePicco
Repo: magicblock-labs/magicblock-validator PR: 738
File: magicblock-chainlink/src/chainlink/fetch_cloner.rs:1109-1196
Timestamp: 2025-12-17T12:46:36.207Z
Learning: In magicblock-chainlink/src/chainlink/fetch_cloner.rs, eATA account subscriptions are intentionally NOT cancelled even when the eATA doesn't exist or delegation conversion fails. The subscriptions are kept active to watch for future creation or delegation of eATA accounts (per maintainer GabrielePicco).
Applied to files:
magicblock-chainlink/src/chainlink/fetch_cloner.rsmagicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rsmagicblock-chainlink/src/submux/mod.rs
📚 Learning: 2025-11-13T09:38:43.804Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: magicblock-processor/src/scheduler/locks.rs:64-102
Timestamp: 2025-11-13T09:38:43.804Z
Learning: In magicblock-processor's TransactionScheduler (scheduler/mod.rs line 59), the executor count is clamped to MAX_SVM_EXECUTORS (63) at initialization time, and executor IDs are assigned sequentially from 0 to count-1. This architectural guarantee ensures that executor IDs used in the bitmask-based AccountLock (scheduler/locks.rs) will always be within valid bounds for bit shifting operations, making runtime bounds checks unnecessary.
Applied to files:
magicblock-processor/src/executor/processing.rsmagicblock-processor/src/executor/mod.rsmagicblock-processor/tests/scheduling.rsmagicblock-processor/src/scheduler/tests.rsmagicblock-processor/src/scheduler/mod.rsmagicblock-task-scheduler/src/service.rsmagicblock-processor/src/scheduler/locks.rsmagicblock-api/src/magic_validator.rstest-kit/src/lib.rsmagicblock-processor/src/scheduler/coordinator.rs
📚 Learning: 2025-11-04T10:53:50.922Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: magicblock-processor/src/scheduler/locks.rs:110-122
Timestamp: 2025-11-04T10:53:50.922Z
Learning: In magicblock-processor, the TransactionScheduler runs in a single, dedicated thread and will always remain single-threaded. The `next_transaction_id()` function in scheduler/locks.rs uses `unsafe static mut` which is safe given this architectural guarantee.
Applied to files:
magicblock-processor/src/executor/mod.rsmagicblock-processor/tests/scheduling.rsmagicblock-processor/src/scheduler/tests.rsmagicblock-processor/src/scheduler/mod.rsmagicblock-task-scheduler/src/service.rsmagicblock-processor/src/scheduler/locks.rsmagicblock-api/src/magic_validator.rstest-kit/src/lib.rsmagicblock-processor/src/scheduler/coordinator.rs
📚 Learning: 2025-11-07T13:09:52.253Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: test-kit/src/lib.rs:275-0
Timestamp: 2025-11-07T13:09:52.253Z
Learning: In test-kit, the transaction scheduler in ExecutionTestEnv is not expected to shut down during tests. Therefore, using `.unwrap()` in test helper methods like `schedule_transaction` is acceptable and will not cause issues in the test environment.
Applied to files:
magicblock-processor/src/executor/mod.rsmagicblock-processor/tests/scheduling.rsmagicblock-processor/src/scheduler/tests.rsmagicblock-processor/src/scheduler/mod.rsmagicblock-task-scheduler/src/service.rsmagicblock-processor/tests/security.rsmagicblock-api/src/magic_validator.rstest-kit/src/lib.rsmagicblock-processor/tests/fees.rsmagicblock-processor/src/scheduler/coordinator.rs
📚 Learning: 2025-12-01T16:02:05.367Z
Learnt from: thlorenz
Repo: magicblock-labs/magicblock-validator PR: 703
File: magicblock-chainlink/src/submux/mod.rs:652-654
Timestamp: 2025-12-01T16:02:05.367Z
Learning: In magicblock-chainlink/src/submux/mod.rs, the subscribe_program method intentionally adds program_id to program_subs before attempting the subscription. This ensures that even if the initial subscription fails or only partially succeeds across clients, the reconnection logic will retry the subscription. This is a deliberate design pattern for resilience in the multi-client architecture and should not be "fixed" to remove entries on failure.
Applied to files:
magicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rsmagicblock-metrics/src/metrics/mod.rsmagicblock-chainlink/src/submux/mod.rsmagicblock-task-scheduler/src/service.rs
📚 Learning: 2025-10-26T16:53:29.820Z
Learnt from: thlorenz
Repo: magicblock-labs/magicblock-validator PR: 587
File: magicblock-chainlink/src/remote_account_provider/mod.rs:134-0
Timestamp: 2025-10-26T16:53:29.820Z
Learning: In magicblock-chainlink/src/remote_account_provider/mod.rs, the `Endpoint::separate_pubsub_url_and_api_key()` method uses `split_once("?api-key=")` because the api-key parameter is always the only query parameter right after `?`. No additional query parameter parsing is needed for this use case.
Applied to files:
magicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rsmagicblock-api/src/magic_validator.rs
📚 Learning: 2025-11-07T13:20:13.793Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: magicblock-processor/src/scheduler/coordinator.rs:227-238
Timestamp: 2025-11-07T13:20:13.793Z
Learning: In magicblock-processor's ExecutionCoordinator (scheduler/coordinator.rs), the `account_contention` HashMap intentionally does not call `shrink_to_fit()`. Maintaining slack capacity is beneficial for performance by avoiding frequent reallocations during high transaction throughput. As long as empty entries are removed from the map (which `clear_account_contention` does), the capacity overhead is acceptable.
Applied to files:
magicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rsmagicblock-processor/src/scheduler/tests.rsmagicblock-processor/src/scheduler/mod.rsmagicblock-processor/src/scheduler/locks.rsmagicblock-api/src/magic_validator.rsmagicblock-processor/src/scheduler/coordinator.rs
📚 Learning: 2025-10-14T09:56:14.047Z
Learnt from: taco-paco
Repo: magicblock-labs/magicblock-validator PR: 564
File: test-integration/programs/flexi-counter/src/processor/call_handler.rs:122-125
Timestamp: 2025-10-14T09:56:14.047Z
Learning: The file test-integration/programs/flexi-counter/src/processor/call_handler.rs contains a test smart contract used for integration testing, not production code.
Applied to files:
magicblock-processor/tests/scheduling.rsmagicblock-processor/tests/security.rsmagicblock-aperture/tests/node.rstest-integration/test-ledger-restore/src/lib.rsmagicblock-processor/tests/fees.rs
📚 Learning: 2025-11-12T09:46:27.553Z
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 614
File: magicblock-task-scheduler/src/db.rs:26-0
Timestamp: 2025-11-12T09:46:27.553Z
Learning: In magicblock-task-scheduler, task parameter validation (including ensuring iterations > 0 and enforcing minimum execution intervals) is performed in the Magic program (on-chain) before ScheduleTaskRequest instances reach the scheduler service. The From<&ScheduleTaskRequest> conversion in db.rs does not need additional validation because inputs are already validated at the program level.
Applied to files:
magicblock-processor/tests/scheduling.rsmagicblock-processor/src/scheduler/tests.rsmagicblock-processor/src/scheduler/mod.rsmagicblock-task-scheduler/src/service.rstest-integration/test-task-scheduler/src/lib.rsmagicblock-api/src/magic_validator.rsCargo.toml
📚 Learning: 2025-11-19T12:55:48.931Z
Learnt from: Dodecahedr0x
Repo: magicblock-labs/magicblock-validator PR: 639
File: test-integration/test-tools/src/validator.rs:193-197
Timestamp: 2025-11-19T12:55:48.931Z
Learning: In the magicblock-validator codebase, when constructing arguments for the light CLI test validator in start_light_validator_with_config (test-integration/test-tools/src/validator.rs), the shlex::split approach is necessary because the light CLI does not handle whitespaces properly in validator arguments. The string concatenation + shlex parsing pattern should not be refactored to direct argument construction in this specific case.
Applied to files:
test-integration/test-config/tests/auto_airdrop_feepayer.rsmagicblock-config/src/config/cli.rsCargo.toml
📚 Learning: 2025-11-20T08:57:07.217Z
Learnt from: thlorenz
Repo: magicblock-labs/magicblock-validator PR: 650
File: magicblock-chainlink/src/submux/subscription_task.rs:13-99
Timestamp: 2025-11-20T08:57:07.217Z
Learning: In the magicblock-validator repository, avoid posting review comments that merely confirm code is correct or matches intended behavior without providing actionable feedback, suggestions for improvement, or identifying potential issues. Such confirmatory comments are considered unhelpful noise by the maintainers.
Applied to files:
docs/CONTRIBUTING.mdmagicblock-task-scheduler/src/service.rsCargo.toml
📚 Learning: 2025-11-21T11:03:26.756Z
Learnt from: thlorenz
Repo: magicblock-labs/magicblock-validator PR: 664
File: magicblock-chainlink/src/testing/mod.rs:342-370
Timestamp: 2025-11-21T11:03:26.756Z
Learning: In the magicblock-validator codebase, avoid leaving review comments that merely acknowledge code is correct or well-structured when there is no actionable suggestion, improvement, or issue to flag. Only comment when there is something specific to recommend, fix, or clarify.
Applied to files:
docs/CONTRIBUTING.mdmagicblock-task-scheduler/src/service.rsCargo.toml
📚 Learning: 2025-10-21T13:06:38.900Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 578
File: magicblock-aperture/src/requests/http/get_program_accounts.rs:17-25
Timestamp: 2025-10-21T13:06:38.900Z
Learning: The magicblock validator does not support ledger forking, so commitment-based state queries (processed/confirmed/finalized) are not applicable. RPC methods can safely ignore commitment and minContextSlot parameters from Solana RPC config objects.
Applied to files:
docs/CONTRIBUTING.mdmagicblock-api/src/magic_validator.rs
📚 Learning: 2025-11-04T10:48:00.070Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 589
File: magicblock-processor/src/scheduler/mod.rs:217-219
Timestamp: 2025-11-04T10:48:00.070Z
Learning: In magicblock-validator, the codebase uses a pattern where types containing non-Send/non-Sync fields (like Rc<RefCell<...>>) are marked with unsafe impl Send when they are guaranteed to be confined to a single thread through careful API design and thread spawning patterns.
Applied to files:
test-integration/test-config/src/lib.rstest-kit/src/lib.rs
📚 Learning: 2025-10-28T13:15:42.706Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 596
File: magicblock-processor/src/scheduler.rs:1-1
Timestamp: 2025-10-28T13:15:42.706Z
Learning: In magicblock-processor, transaction indexes were always set to 0 even before the changes in PR #596. The proper transaction indexing within slots will be addressed during the planned ledger rewrite.
Applied to files:
magicblock-task-scheduler/src/service.rsmagicblock-api/src/magic_validator.rs
📚 Learning: 2025-11-20T17:25:23.444Z
Learnt from: JMirval
Repo: magicblock-labs/magicblock-validator PR: 656
File: programs/guinea/src/lib.rs:33-33
Timestamp: 2025-11-20T17:25:23.444Z
Learning: In the magicblock-validator codebase, task IDs (task_id) are i64 values that can be negative. The task scheduler is designed to handle any i64 value including negative task IDs. Task IDs are randomly generated using rand::random() which produces values across the full i64 range. No validation is needed to restrict task IDs to positive values.
Applied to files:
magicblock-task-scheduler/src/service.rs
📚 Learning: 2025-10-21T10:34:59.140Z
Learnt from: bmuddha
Repo: magicblock-labs/magicblock-validator PR: 578
File: magicblock-accounts-db/src/lib.rs:63-72
Timestamp: 2025-10-21T10:34:59.140Z
Learning: In magicblock-validator, the AccountsDb "stop-the-world" synchronizer is managed at the processor/executor level, not at the AccountsDb API level. Transaction executors in magicblock-processor hold a read lock (sync.read()) for the duration of each slot and release it only at slot boundaries, ensuring all account writes happen under the read lock. Snapshot operations acquire a write lock, blocking until all executors release their read locks. This pattern ensures mutual exclusion between writes and snapshots without requiring read guards in AccountsDb write APIs.
Applied to files:
magicblock-processor/src/scheduler/locks.rsmagicblock-processor/src/scheduler/coordinator.rs
📚 Learning: 2025-10-26T16:54:39.084Z
Learnt from: thlorenz
Repo: magicblock-labs/magicblock-validator PR: 587
File: test-manual/Cargo.toml:0-0
Timestamp: 2025-10-26T16:54:39.084Z
Learning: In the magicblock-validator repository, use git branch references (not commit hashes or tags) for the helius-laserstream dependency to allow automatic updates when the branch is pushed to.
Applied to files:
magicblock-api/src/magic_validator.rs
🧬 Code graph analysis (23)
magicblock-aperture/src/requests/http/request_airdrop.rs (1)
magicblock-aperture/src/requests/mod.rs (1)
params(27-31)
magicblock-table-mania/src/manager.rs (1)
magicblock-committor-service/src/intent_execution_manager/intent_execution_engine.rs (1)
rand(666-666)
magicblock-chainlink/src/remote_account_provider/chain_pubsub_actor.rs (3)
magicblock-metrics/src/metrics/mod.rs (1)
inc_program_subscription_account_updates(641-645)magicblock-table-mania/src/lookup_table_rc.rs (1)
contains_key(308-311)magicblock-chainlink/src/remote_account_provider/config.rs (1)
program_subs(74-76)
magicblock-processor/tests/scheduling.rs (3)
test-kit/src/lib.rs (4)
new_with_config(99-162)new(87-89)get_transaction(210-218)get_account(311-321)magicblock-processor/src/executor/mod.rs (1)
new(73-118)magicblock-processor/src/scheduler/mod.rs (1)
new(58-91)
test-integration/test-config/tests/auto_airdrop_feepayer.rs (2)
magicblock-config/src/types/network.rs (2)
from_str(63-81)from_str(133-142)test-integration/test-tools/src/integration_test_context.rs (2)
url_chain(1151-1153)ws_url_chain(1154-1156)
magicblock-processor/src/scheduler/tests.rs (1)
magicblock-processor/src/scheduler/coordinator.rs (5)
new(33-38)new(60-69)try_acquire_locks(148-221)get_ready_executor(116-118)next_blocked_transaction(136-141)
magicblock-processor/src/scheduler/mod.rs (2)
magicblock-processor/src/executor/mod.rs (4)
new(73-118)spawn(142-153)run(167-207)transition_to_new_slot(211-216)magicblock-processor/src/scheduler/coordinator.rs (3)
new(33-38)new(60-69)is_ready(110-112)
test-integration/test-config/src/lib.rs (2)
magicblock-config/src/types/network.rs (2)
from_str(63-81)from_str(133-142)test-integration/test-tools/src/integration_test_context.rs (2)
url_chain(1151-1153)ws_url_chain(1154-1156)
magicblock-config/src/lib.rs (1)
magicblock-config/src/types/network.rs (1)
websocket(42-44)
magicblock-task-scheduler/src/service.rs (1)
magicblock-core/src/link.rs (1)
link(60-89)
magicblock-processor/tests/security.rs (1)
test-kit/src/lib.rs (3)
new_with_config(99-162)new(87-89)get_payer(323-329)
magicblock-metrics/src/metrics/types.rs (3)
magicblock-committor-service/src/intent_executor/error.rs (2)
value(120-132)value(247-255)magicblock-committor-service/src/intent_executor/mod.rs (1)
value(75-83)magicblock-committor-service/src/types.rs (1)
value(23-29)
test-integration/test-task-scheduler/src/lib.rs (2)
magicblock-config/src/types/network.rs (2)
from_str(63-81)from_str(133-142)test-integration/test-tools/src/integration_test_context.rs (2)
url_chain(1151-1153)ws_url_chain(1154-1156)
magicblock-aperture/tests/mocked.rs (1)
test-kit/src/lib.rs (1)
get_payer(323-329)
magicblock-api/src/magic_validator.rs (2)
magicblock-api/src/domain_registry_manager.rs (1)
new(26-33)magicblock-config/src/lib.rs (1)
rpc_url(154-159)
magicblock-config/src/types/network.rs (1)
test-integration/test-tools/src/toml_to_args.rs (1)
url(27-44)
test-integration/test-tools/src/toml_to_args.rs (1)
magicblock-config/src/types/network.rs (2)
from_str(63-81)from_str(133-142)
magicblock-aperture/tests/node.rs (1)
test-kit/src/lib.rs (1)
get_payer(323-329)
test-kit/src/lib.rs (1)
test-integration/test-schedule-intent/tests/test_schedule_intents.rs (5)
payers(172-172)payers(194-194)payers(228-228)payers(244-244)payers(271-271)
magicblock-config/src/tests.rs (1)
magicblock-config/src/types/network.rs (1)
url_str(86-92)
test-integration/test-ledger-restore/src/lib.rs (2)
magicblock-config/src/types/network.rs (2)
from_str(63-81)from_str(133-142)test-integration/test-tools/src/integration_test_context.rs (2)
url_chain(1151-1153)ws_url_chain(1154-1156)
magicblock-processor/tests/fees.rs (1)
test-kit/src/lib.rs (2)
get_payer(323-329)new_with_config(99-162)
magicblock-processor/src/scheduler/coordinator.rs (1)
magicblock-processor/src/scheduler/locks.rs (1)
next_transaction_id(106-117)
🪛 LanguageTool
docs/GOVERNANCE.md
[uncategorized] ~48-~48: The official name of this software platform is spelled with a capital “H”.
Context: .... ### The Code Ownership Manifest The .github/CODEOWNERS file serves as the definiti...
(GITHUB)
[style] ~95-~95: This phrase is redundant. Consider writing “consult”.
Context: ... significant changes, the assignee must consult with the CO of the affected crate(s) to alig...
(CONSULT_WITH)
🪛 markdownlint-cli2 (0.18.1)
docs/GOVERNANCE.md
7-7: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3
(MD001, heading-increment)
| prost = "0.11.9" | ||
| protobuf-src = "1.1" | ||
| rand = "0.8.5" | ||
| rand = "0.9" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check for rand usage patterns that may have changed in 0.9
echo "=== Checking gen_range usage ==="
rg -n "\.gen_range\(" --type rust
echo "=== Checking use rand:: imports ==="
rg -n "use rand::" --type rust
echo "=== Checking rand::Rng usage ==="
rg -n "rand::Rng" --type rustRepository: magicblock-labs/magicblock-validator
Length of output: 477
🏁 Script executed:
#!/bin/bash
# Check usage around the rand::Rng imports
echo "=== File 1: test-integration/test-committor-service/tests/common.rs ==="
sed -n '140,150p' test-integration/test-committor-service/tests/common.rs
echo -e "\n=== File 2: magicblock-table-mania/src/manager.rs ==="
sed -n '377,390p' magicblock-table-mania/src/manager.rsRepository: magicblock-labs/magicblock-validator
Length of output: 1079
🌐 Web query:
rand 0.9 breaking changes API compatibility major version
💡 Result:
Summary — rand 0.9 breaking / compatibility highlights
-
Version and policy: rand 0.9 was released Jan 2025; rand is still 0.x so minor releases may contain breaking changes per SemVer-for-0.x. See the release/upgrade guide. [1][2]
-
Major, visible API breaks in 0.9 (examples):
- Top-level/trait renames: rand::thread_rng() → rand::rng(); Rng::gen → random; Rng::gen_range → random_range (and several related renames/re-introductions). [3]
- rand_core trait changes: new traits TryRngCore/TryCryptoRng; SeedableRng::from_rng renamed to try_from_rng and a new from_rng added; other signature/associated-type bound changes. [3][4]
- Distribution / API reorganisations (e.g., WeightedIndex moved/renamed items). [1]
-
Behavioural / reproducibility-breaking changes:
- Some RNG/distribution operations had changes that can alter produced sequences (ReseedingRng reseed behaviour, SmallRng seeding, Uniform/UniformFloat changes, sampling optimisations). The project documents which items are non‑portable/don’t guarantee cross-version reproducibility (e.g., SmallRng, StdRng). [1][5]
-
Build / feature changes:
- MSRV bumped to Rust 1.63.0; feature-name changes (serde1 → serde, getrandom → os_rng, rand_chacha implicit feature removed; new feature names like std_rng, thread_rng, small_rng defaults). [3][5]
-
Compatibility guidance:
- Read the rand 0.9 upgrade guide and CHANGELOG for the full list of API changes and recommended fixes; rand uses some inter-crate “compat” techniques for traits but you must update code for renamed functions/traits and adjust for MSRV/features. [5][3]
Sources
[1] rand CHANGELOG / 0.9.x (docs.rs).
[2] Releases · rust-random/rand · GitHub (0.9 release + upgrade guide).
[3] rand 0.9 release notes / Upgrade guide (rust-random book).
[4] rand_core changelog (rand_core 0.9.x).
[5] Reproducibility / Rand Book (policy on non-portable items).
🏁 Script executed:
#!/bin/bash
# Search for .gen() method calls more thoroughly
rg -n "\.gen\(" --type rust -A 2 -B 2Repository: magicblock-labs/magicblock-validator
Length of output: 466
Update rand usage for 0.9 API compatibility.
rand 0.9 contains breaking changes: rand::thread_rng() → rand::rng(), Rng::gen() → random(), Rng::gen_range() → random_range(). The codebase has incompatible usage at test-integration/test-committor-service/tests/common.rs:146 (rand::thread_rng() and .gen() calls) that will fail to compile. Update this to use rand::rng() and the appropriate method for the intended behavior.
| ### 1. Guiding Principles | ||
|
|
||
| This framework’s purpose is to balance development velocity with high-quality standards. It is guided by these principles: | ||
|
|
||
| - **Velocity**: Prioritize shipping value by minimizing time spent in deadlocked debates. | ||
| - **Clarity & Accountability**: Eliminate ambiguity with clearly defined roles and responsibilities. | ||
| - **Quality & Cohesion**: Maintain a consistent architectural vision through empowered, accountable owners. | ||
| - **Fair Process**: Ensure no single authority is absolute by providing a structured path for resolving disputes and ratifying significant changes. | ||
|
|
||
| --- | ||
|
|
||
| ### 2. On Professional Conduct & Disagreements | ||
|
|
||
| This framework is designed to facilitate healthy, professional debate. All discussions, especially during disputes, must be guided by the following principles: | ||
|
|
||
| **Critique ideas, not people.** Arguments must be directed at the technical approach, code, or design, never at an individual. Assume good intent from all participants. A challenge to a technical decision is not a personal attack; it is an attempt to find the best outcome for the project. | ||
|
|
||
| Once a decision is reached, it is final. All team members are expected to **disagree and commit**—meaning even if you argued for a different path during the debate, you must fully support the execution of the final decision. | ||
|
|
||
| --- | ||
|
|
||
| ### 3. Categories of Decisions & Grounds for Conflict | ||
|
|
||
| To provide a clear basis for discussion, decisions and potential conflicts are classified into three categories. Each category maps to a specific resolution path within our governance model. | ||
|
|
||
| 1. **High-Level System Architecture**: Decisions concerning the fundamental structure of the system, cross-crate interactions, major dependencies, and core infrastructure. | ||
| 2. **Implementation Details**: The specific logic, algorithms, and methods used to solve a problem *within the scope of a single crate*. | ||
| 3. **Code Style & Patterns**: Choices related to formatting, naming conventions, and common patterns, guided by consistency with the existing codebase and global standards. | ||
|
|
||
| --- | ||
|
|
||
| ### 4. The Code Ownership Model | ||
|
|
||
| Clear ownership is the foundation of this framework. It ensures every part of the codebase has a designated steward. | ||
|
|
||
| ### The Unit of Ownership | ||
|
|
||
| The fundamental unit of ownership is the **Cargo Crate**. | ||
|
|
||
| ### The Code Ownership Manifest | ||
|
|
||
| The `.github/CODEOWNERS` file serves as the definitive source of truth for ownership. | ||
|
|
||
| ### Becoming a Code Owner | ||
|
|
||
| 1. **New Crates (Default)**: The primary author designates themselves as the CO in the initial PR. | ||
| 2. **Unowned Crates (Claim)**: Any team member can claim an unowned crate via a PR with at least one approval. | ||
| 3. **Transfer of Ownership (Exceptional)**: Transfers require a formal proposal and vote by the Consensus Council. | ||
|
|
||
| ### Responsibilities & Authority of the Code Owner | ||
|
|
||
| The CO is the steward for their crate(s), responsible for quality and consistency. Their approval is necessary to merge a PR. They hold the **Steward's Prerogative** to make final decisions on **Implementation Details** and **Code Style** within their crate to break deadlocks. | ||
|
|
||
| --- | ||
|
|
||
| ### 5. The Decision-Making & Escalation Framework | ||
|
|
||
| This framework establishes a clear, three-tiered structure for making decisions. | ||
|
|
||
| ### Tier 1: The Code Owner (Default Authority) | ||
|
|
||
| - **Domain**: **Implementation Details** and **Code Style & Patterns** within their owned crate. | ||
| - **Process**: The CO has the final decision-making authority. | ||
|
|
||
| ### Tier 2: The Consensus Council (Dispute & Architectural Governance) | ||
|
|
||
| - **Domain**: **High-Level System Architecture**, proposals for new **Global Code Styles**, and disputed Tier 1 decisions. | ||
| - **Process**: The Council is the primary body for resolving disputes and ratifying significant, team-wide changes. | ||
|
|
||
| ### Tier 3: The CTO (Final Tie-Breaker) | ||
|
|
||
| - **Domain**: Deadlocked Council votes. | ||
| - **Process**: In the rare event the Council cannot reach a supermajority, the **CTO will cast the final, tie-breaking vote**. | ||
|
|
||
| --- | ||
|
|
||
| ### 6. The Consensus Council Protocol | ||
|
|
||
| - **Formation**: The Council is formed on-demand from all members of the Labs team. | ||
| - **Timeboxing**: Votes are time-boxed to **24 hours**. This can be extended by a simple majority vote. | ||
| - **Supermajority Rule**: A motion passes only if it receives affirmative votes from **two-thirds (2/3) of the entire Council membership**. Abstention or non-participation counts against the motion's success. | ||
|
|
||
| --- | ||
|
|
||
| ### 7. Standard Workflows | ||
|
|
||
| ### 7.1. Design Consultation | ||
|
|
||
| Before implementing significant changes, the assignee must consult with the CO of the affected crate(s) to align on the proposed design and impact. For minor changes, a brief message suffices. | ||
|
|
||
| ### 7.2. PR Review Process | ||
|
|
||
| 1. **Initiation**: The PR author notifies the relevant CO(s) upon opening a PR. | ||
| 2. **Review**: The CO prioritizes the review. If a discussion reaches an impasse, the CO is empowered to use the **Steward's Prerogative**. | ||
| 3. **Escalation (Optional)**: If a reviewer or author strongly disagrees with the CO's decision, they may formally escalate the matter to the **Consensus Council**. | ||
| 4. **Resolution**: The Council resolves the dispute within 24 hours. The outcome is final. | ||
|
|
There was a problem hiding this comment.
Fix markdown heading hierarchy.
Markdown heading levels should increment by one level at a time. All major section headings (lines 7, 18, 28, 38, 62, 83, 91) use ### (h3) but should use ## (h2) to follow directly beneath the main h1 heading.
🔎 Proposed fix for heading hierarchy
- ### 1. Guiding Principles
+ ## 1. Guiding Principles
- ### 2. On Professional Conduct & Disagreements
+ ## 2. On Professional Conduct & Disagreements
- ### 3. Categories of Decisions & Grounds for Conflict
+ ## 3. Categories of Decisions & Grounds for Conflict
- ### 4. The Code Ownership Model
+ ## 4. The Code Ownership Model
- ### 5. The Decision-Making & Escalation Framework
+ ## 5. The Decision-Making & Escalation Framework
- ### 6. The Consensus Council Protocol
+ ## 6. The Consensus Council Protocol
- ### 7. Standard Workflows
+ ## 7. Standard WorkflowsNote: Nested subsections (e.g., "4.1", "5.1", "6", "7.1", "7.2") that currently use ### should remain ### (h3) after this change, as they will then correctly be one level beneath the h2 sections.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ### 1. Guiding Principles | |
| This framework’s purpose is to balance development velocity with high-quality standards. It is guided by these principles: | |
| - **Velocity**: Prioritize shipping value by minimizing time spent in deadlocked debates. | |
| - **Clarity & Accountability**: Eliminate ambiguity with clearly defined roles and responsibilities. | |
| - **Quality & Cohesion**: Maintain a consistent architectural vision through empowered, accountable owners. | |
| - **Fair Process**: Ensure no single authority is absolute by providing a structured path for resolving disputes and ratifying significant changes. | |
| --- | |
| ### 2. On Professional Conduct & Disagreements | |
| This framework is designed to facilitate healthy, professional debate. All discussions, especially during disputes, must be guided by the following principles: | |
| **Critique ideas, not people.** Arguments must be directed at the technical approach, code, or design, never at an individual. Assume good intent from all participants. A challenge to a technical decision is not a personal attack; it is an attempt to find the best outcome for the project. | |
| Once a decision is reached, it is final. All team members are expected to **disagree and commit**—meaning even if you argued for a different path during the debate, you must fully support the execution of the final decision. | |
| --- | |
| ### 3. Categories of Decisions & Grounds for Conflict | |
| To provide a clear basis for discussion, decisions and potential conflicts are classified into three categories. Each category maps to a specific resolution path within our governance model. | |
| 1. **High-Level System Architecture**: Decisions concerning the fundamental structure of the system, cross-crate interactions, major dependencies, and core infrastructure. | |
| 2. **Implementation Details**: The specific logic, algorithms, and methods used to solve a problem *within the scope of a single crate*. | |
| 3. **Code Style & Patterns**: Choices related to formatting, naming conventions, and common patterns, guided by consistency with the existing codebase and global standards. | |
| --- | |
| ### 4. The Code Ownership Model | |
| Clear ownership is the foundation of this framework. It ensures every part of the codebase has a designated steward. | |
| ### The Unit of Ownership | |
| The fundamental unit of ownership is the **Cargo Crate**. | |
| ### The Code Ownership Manifest | |
| The `.github/CODEOWNERS` file serves as the definitive source of truth for ownership. | |
| ### Becoming a Code Owner | |
| 1. **New Crates (Default)**: The primary author designates themselves as the CO in the initial PR. | |
| 2. **Unowned Crates (Claim)**: Any team member can claim an unowned crate via a PR with at least one approval. | |
| 3. **Transfer of Ownership (Exceptional)**: Transfers require a formal proposal and vote by the Consensus Council. | |
| ### Responsibilities & Authority of the Code Owner | |
| The CO is the steward for their crate(s), responsible for quality and consistency. Their approval is necessary to merge a PR. They hold the **Steward's Prerogative** to make final decisions on **Implementation Details** and **Code Style** within their crate to break deadlocks. | |
| --- | |
| ### 5. The Decision-Making & Escalation Framework | |
| This framework establishes a clear, three-tiered structure for making decisions. | |
| ### Tier 1: The Code Owner (Default Authority) | |
| - **Domain**: **Implementation Details** and **Code Style & Patterns** within their owned crate. | |
| - **Process**: The CO has the final decision-making authority. | |
| ### Tier 2: The Consensus Council (Dispute & Architectural Governance) | |
| - **Domain**: **High-Level System Architecture**, proposals for new **Global Code Styles**, and disputed Tier 1 decisions. | |
| - **Process**: The Council is the primary body for resolving disputes and ratifying significant, team-wide changes. | |
| ### Tier 3: The CTO (Final Tie-Breaker) | |
| - **Domain**: Deadlocked Council votes. | |
| - **Process**: In the rare event the Council cannot reach a supermajority, the **CTO will cast the final, tie-breaking vote**. | |
| --- | |
| ### 6. The Consensus Council Protocol | |
| - **Formation**: The Council is formed on-demand from all members of the Labs team. | |
| - **Timeboxing**: Votes are time-boxed to **24 hours**. This can be extended by a simple majority vote. | |
| - **Supermajority Rule**: A motion passes only if it receives affirmative votes from **two-thirds (2/3) of the entire Council membership**. Abstention or non-participation counts against the motion's success. | |
| --- | |
| ### 7. Standard Workflows | |
| ### 7.1. Design Consultation | |
| Before implementing significant changes, the assignee must consult with the CO of the affected crate(s) to align on the proposed design and impact. For minor changes, a brief message suffices. | |
| ### 7.2. PR Review Process | |
| 1. **Initiation**: The PR author notifies the relevant CO(s) upon opening a PR. | |
| 2. **Review**: The CO prioritizes the review. If a discussion reaches an impasse, the CO is empowered to use the **Steward's Prerogative**. | |
| 3. **Escalation (Optional)**: If a reviewer or author strongly disagrees with the CO's decision, they may formally escalate the matter to the **Consensus Council**. | |
| 4. **Resolution**: The Council resolves the dispute within 24 hours. The outcome is final. | |
| ## 1. Guiding Principles | |
| This framework's purpose is to balance development velocity with high-quality standards. It is guided by these principles: | |
| - **Velocity**: Prioritize shipping value by minimizing time spent in deadlocked debates. | |
| - **Clarity & Accountability**: Eliminate ambiguity with clearly defined roles and responsibilities. | |
| - **Quality & Cohesion**: Maintain a consistent architectural vision through empowered, accountable owners. | |
| - **Fair Process**: Ensure no single authority is absolute by providing a structured path for resolving disputes and ratifying significant changes. | |
| --- | |
| ## 2. On Professional Conduct & Disagreements | |
| This framework is designed to facilitate healthy, professional debate. All discussions, especially during disputes, must be guided by the following principles: | |
| **Critique ideas, not people.** Arguments must be directed at the technical approach, code, or design, never at an individual. Assume good intent from all participants. A challenge to a technical decision is not a personal attack; it is an attempt to find the best outcome for the project. | |
| Once a decision is reached, it is final. All team members are expected to **disagree and commit**—meaning even if you argued for a different path during the debate, you must fully support the execution of the final decision. | |
| --- | |
| ## 3. Categories of Decisions & Grounds for Conflict | |
| To provide a clear basis for discussion, decisions and potential conflicts are classified into three categories. Each category maps to a specific resolution path within our governance model. | |
| 1. **High-Level System Architecture**: Decisions concerning the fundamental structure of the system, cross-crate interactions, major dependencies, and core infrastructure. | |
| 2. **Implementation Details**: The specific logic, algorithms, and methods used to solve a problem *within the scope of a single crate*. | |
| 3. **Code Style & Patterns**: Choices related to formatting, naming conventions, and common patterns, guided by consistency with the existing codebase and global standards. | |
| --- | |
| ## 4. The Code Ownership Model | |
| Clear ownership is the foundation of this framework. It ensures every part of the codebase has a designated steward. | |
| ### The Unit of Ownership | |
| The fundamental unit of ownership is the **Cargo Crate**. | |
| ### The Code Ownership Manifest | |
| The `.github/CODEOWNERS` file serves as the definitive source of truth for ownership. | |
| ### Becoming a Code Owner | |
| 1. **New Crates (Default)**: The primary author designates themselves as the CO in the initial PR. | |
| 2. **Unowned Crates (Claim)**: Any team member can claim an unowned crate via a PR with at least one approval. | |
| 3. **Transfer of Ownership (Exceptional)**: Transfers require a formal proposal and vote by the Consensus Council. | |
| ### Responsibilities & Authority of the Code Owner | |
| The CO is the steward for their crate(s), responsible for quality and consistency. Their approval is necessary to merge a PR. They hold the **Steward's Prerogative** to make final decisions on **Implementation Details** and **Code Style** within their crate to break deadlocks. | |
| --- | |
| ## 5. The Decision-Making & Escalation Framework | |
| This framework establishes a clear, three-tiered structure for making decisions. | |
| ### Tier 1: The Code Owner (Default Authority) | |
| - **Domain**: **Implementation Details** and **Code Style & Patterns** within their owned crate. | |
| - **Process**: The CO has the final decision-making authority. | |
| ### Tier 2: The Consensus Council (Dispute & Architectural Governance) | |
| - **Domain**: **High-Level System Architecture**, proposals for new **Global Code Styles**, and disputed Tier 1 decisions. | |
| - **Process**: The Council is the primary body for resolving disputes and ratifying significant, team-wide changes. | |
| ### Tier 3: The CTO (Final Tie-Breaker) | |
| - **Domain**: Deadlocked Council votes. | |
| - **Process**: In the rare event the Council cannot reach a supermajority, the **CTO will cast the final, tie-breaking vote**. | |
| --- | |
| ## 6. The Consensus Council Protocol | |
| - **Formation**: The Council is formed on-demand from all members of the Labs team. | |
| - **Timeboxing**: Votes are time-boxed to **24 hours**. This can be extended by a simple majority vote. | |
| - **Supermajority Rule**: A motion passes only if it receives affirmative votes from **two-thirds (2/3) of the entire Council membership**. Abstention or non-participation counts against the motion's success. | |
| --- | |
| ## 7. Standard Workflows | |
| ### 7.1. Design Consultation | |
| Before implementing significant changes, the assignee must consult with the CO of the affected crate(s) to align on the proposed design and impact. For minor changes, a brief message suffices. | |
| ### 7.2. PR Review Process | |
| 1. **Initiation**: The PR author notifies the relevant CO(s) upon opening a PR. | |
| 2. **Review**: The CO prioritizes the review. If a discussion reaches an impasse, the CO is empowered to use the **Steward's Prerogative**. | |
| 3. **Escalation (Optional)**: If a reviewer or author strongly disagrees with the CO's decision, they may formally escalate the matter to the **Consensus Council**. | |
| 4. **Resolution**: The Council resolves the dispute within 24 hours. The outcome is final. |
🧰 Tools
🪛 LanguageTool
[uncategorized] ~48-~48: The official name of this software platform is spelled with a capital “H”.
Context: .... ### The Code Ownership Manifest The .github/CODEOWNERS file serves as the definiti...
(GITHUB)
[style] ~95-~95: This phrase is redundant. Consider writing “consult”.
Context: ... significant changes, the assignee must consult with the CO of the affected crate(s) to alig...
(CONSULT_WITH)
🪛 markdownlint-cli2 (0.18.1)
7-7: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3
(MD001, heading-increment)
| tokio = { workspace = true } | ||
| tokio-util = { workspace = true } | ||
| rocksdb = { workspace = true, default-features = false, features = ["lz4"]} | ||
| rocksdb = { workspace = true } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Find and examine the workspace Cargo.toml
find . -name "Cargo.toml" -type f | head -20Repository: magicblock-labs/magicblock-validator
Length of output: 762
🏁 Script executed:
# Check if there's a workspace member structure and the workspace Cargo.toml
git ls-files "Cargo.toml" | head -10Repository: magicblock-labs/magicblock-validator
Length of output: 90
🏁 Script executed:
# Look for rocksdb configuration at workspace level
rg -A5 '\[workspace\]' Cargo.toml | head -30Repository: magicblock-labs/magicblock-validator
Length of output: 207
🏁 Script executed:
# Check workspace dependencies for rocksdb configuration
rg -A10 '\[workspace\.dependencies\]' Cargo.tomlRepository: magicblock-labs/magicblock-validator
Length of output: 360
🏁 Script executed:
# Alternative: search for rocksdb anywhere in root Cargo.toml
rg -B2 -A5 'rocksdb' Cargo.toml | head -50Repository: magicblock-labs/magicblock-validator
Length of output: 736
🏁 Script executed:
# Check if lz4 feature is mentioned anywhere in workspace config
rg 'lz4' Cargo.tomlRepository: magicblock-labs/magicblock-validator
Length of output: 100
Workspace RocksDB configuration does not include lz4 feature.
The workspace-level rocksdb dependency (version 0.22.0) has the lz4 feature explicitly commented out. By switching to workspace = true, this crate now uses a configuration without lz4 compression support, removing compression capability that was previously enabled. Verify this change is intentional, as it could impact ledger storage efficiency and performance.
| let res = if let ServiceState::Stopped(worker_handle) = self.state { | ||
| worker_handle.join() | ||
| } else { | ||
| warn!("LedgerTruncator was not running, nothing to stop"); | ||
| Ok(()) | ||
| } | ||
| }; | ||
| info!("LedgerTruncator shutdown!"); | ||
|
|
||
| res |
There was a problem hiding this comment.
Log "shutdown!" only on successful join.
The info log is emitted unconditionally, even if worker_handle.join() returns an error. This could mislead during debugging, as the message implies a clean shutdown regardless of the actual result.
🔎 Suggested fix to log conditionally based on result
let res = if let ServiceState::Stopped(worker_handle) = self.state {
worker_handle.join()
} else {
- warn!("LedgerTruncator was not running, nothing to stop");
+ warn!("LedgerTruncator was never started, nothing to join");
Ok(())
};
- info!("LedgerTruncator shutdown!");
+
+ if res.is_ok() {
+ info!("LedgerTruncator shutdown successfully!");
+ } else {
+ error!("LedgerTruncator shutdown with errors!");
+ }
res| }; | ||
| let txn = &executed.loaded_transaction; | ||
| let feepayer = txn.accounts.first(); | ||
| // If the feepayer is priveleged we don't enforce any checks, as those |
There was a problem hiding this comment.
Fix typo in comment.
"priveleged" should be "privileged".
🔎 Suggested fix
- // If the feepayer is priveleged we don't enforce any checks, as those
+ // If the feepayer is privileged we don't enforce any checks, as those📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| // If the feepayer is priveleged we don't enforce any checks, as those | |
| // If the feepayer is privileged we don't enforce any checks, as those |
| // If the feepayer is priveleged we don't enforce any checks, as those | ||
| // are internal operations, that might violate some of those rules | ||
| if feepayer.as_ref().map(|a| a.1.privileged()).unwrap_or(false) { | ||
| return; | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Verify privileged flag usage and ensure it cannot be exploited.
# Search for where the privileged flag is set
echo "=== Searching for privileged flag assignments ==="
rg -nP --type=rust -C3 '\.set_privileged\(|privileged\s*[:=]\s*true'
# Search for other uses of privileged() method
echo -e "\n=== Other uses of privileged flag ==="
rg -nP --type=rust -C3 '\.privileged\(\)'
# Search for LockedAccount or account types that might have privileged field
echo -e "\n=== Privileged field definitions ==="
ast-grep --pattern 'struct $_ {
$$$
privileged: $_
$$$
}'Repository: magicblock-labs/magicblock-validator
Length of output: 2013
🏁 Script executed:
#!/bin/bash
# Check the fund_account context to understand when privileged is set
echo "=== Context around set_privileged call ==="
cat -n magicblock-api/src/fund_account.rs | head -60
# Search for Account or LockedAccount struct definition
echo -e "\n=== Search for account struct definitions ==="
rg -nP --type=rust 'pub struct.*Account|struct.*Account' -A 10 | head -100
# Find where the validation checks are implemented
echo -e "\n=== Validation check functions ==="
rg -nP --type=rust 'gasless|confined.*lamport' -B 2 -A 5Repository: magicblock-labs/magicblock-validator
Length of output: 19072
🏁 Script executed:
#!/bin/bash
# Look at the complete verify_account_states function
echo "=== verify_account_states function context ==="
sed -n '345,410p' magicblock-processor/src/executor/processing.rs
# Check if there are tests for privileged behavior
echo -e "\n=== Tests mentioning privileged ==="
rg -nP --type=rust 'privileged|init_validator' test-kit/src/lib.rs -B 2 -A 5
# Look for broader context of the reviewed change
echo -e "\n=== Processing module to understand RPC client changes ==="
head -50 magicblock-processor/src/executor/processing.rs | tail -30Repository: magicblock-labs/magicblock-validator
Length of output: 4808
🏁 Script executed:
#!/bin/bash
# Check git log for recent changes to this file
echo "=== Recent commits to processing.rs ==="
git log --oneline -20 magicblock-processor/src/executor/processing.rs
# Search for mentions of RPC client or task executor in the codebase
echo -e "\n=== References to RPC client or task executor ==="
rg -nP --type=rust 'rpc|task.*executor|TaskExecutor' magicblock-processor/src/executor/ -l
# Check if there are test cases that verify privileged behavior
echo -e "\n=== Test files in processor ==="
find magicblock-processor/tests -type f -name "*.rs" | head -10
# Look for any tests that might exercise privileged accounts
echo -e "\n=== Checking security tests for privileged account handling ==="
grep -n "privileged\|validator\|init_validator" magicblock-processor/tests/security.rs || echo "No privileged tests found in security.rs"Repository: magicblock-labs/magicblock-validator
Length of output: 603
Add test coverage for privileged account validation bypass and clarify privileged account semantics.
The early-exit at lines 351-355 bypasses critical validation checks (gasless feepayer modification and confined account lamport modification checks) when the feepayer is privileged. While the privileged flag cannot be exploited at runtime—it's set exclusively during validator initialization and cannot be modified by transactions—there are two substantive issues:
-
Missing test coverage: The security test suite validates these checks for normal accounts but has no test coverage for the privileged bypass path. Add a test confirming privileged accounts bypass these validations as intended.
-
Documentation: The inline comment explaining "privileged" is minimal. Document what privileged means (validator identity account for internal operations), when the flag is set, and what security guarantees this bypass provides.
Consider addressing the scope concern separately if this change is unrelated to the PR's primary objective.
| ## ⚙️ Configuration | ||
|
|
||
| The validator supports configurations for the different use cases. The configuration files is a TOML file (some examples can be found in [configs](./configs)). Additionally, the configuration can be overridden by environment variables. | ||
| The validator is highly configurable via TOML files or environment variables. A comprehensive reference configuration is available in [`config.example.toml`](https://www.google.com/search?q=./config.example.toml). |
There was a problem hiding this comment.
Fix broken documentation link.
Line 59 uses a Google search URL instead of a proper file reference. This should link directly to the configuration file.
🔎 Proposed fix
-The validator is highly configurable via TOML files or environment variables. A comprehensive reference configuration is available in [`config.example.toml`](https://www.google.com/search?q=./config.example.toml).
+The validator is highly configurable via TOML files or environment variables. A comprehensive reference configuration is available in [`config.example.toml`](./config.example.toml).📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| The validator is highly configurable via TOML files or environment variables. A comprehensive reference configuration is available in [`config.example.toml`](https://www.google.com/search?q=./config.example.toml). | |
| The validator is highly configurable via TOML files or environment variables. A comprehensive reference configuration is available in [`config.example.toml`](./config.example.toml). |
| # Example: Run as an ephemeral validator syncing from Mainnet | ||
| MBV_LIFECYCLE=ephemeral \ | ||
| MBV_LISTEN=0.0.0.0:8899 \ | ||
| cargo run --release config.example.toml |
There was a problem hiding this comment.
Correct the cargo command syntax.
The cargo run command is missing the -- separator between cargo arguments and program arguments, which could cause the config file path to be interpreted as a cargo argument.
🔎 Proposed fix
-MBV_LIFECYCLE=ephemeral \
-MBV_LISTEN=0.0.0.0:8899 \
-cargo run --release config.example.toml
+MBV_LIFECYCLE=ephemeral \
+MBV_LISTEN=0.0.0.0:8899 \
+cargo run --release -- config.example.tomlCommittable suggestion skipped: line range outside the PR's diff.
| ### **3. Run the integration test, e.g:** | ||
|
|
||
| * **Run integration tests specifically:** | ||
| See [test-integration/README.md](https://www.google.com/search?q=./test-integration/README.md) for detailed instructions on running specific scenarios. |
There was a problem hiding this comment.
Fix broken documentation link.
Line 130 uses a Google search URL instead of a proper file reference. This should link directly to the test integration README.
🔎 Proposed fix
-See [test-integration/README.md](https://www.google.com/search?q=./test-integration/README.md) for detailed instructions on running specific scenarios.
+See [test-integration/README.md](./test-integration/README.md) for detailed instructions on running specific scenarios.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| See [test-integration/README.md](https://www.google.com/search?q=./test-integration/README.md) for detailed instructions on running specific scenarios. | |
| See [test-integration/README.md](./test-integration/README.md) for detailed instructions on running specific scenarios. |
| ## 📄 License | ||
|
|
||
| The Ephemeral Validator is in active development, so all APIs are subject to change. This code is unaudited. Use at your own risk. | ||
| This project is licensed under the **Business Source License 1.1**. See [LICENSE.md](https://www.google.com/search?q=./LICENSE.md) for details. |
There was a problem hiding this comment.
Fix broken documentation link.
Line 158 uses a Google search URL instead of a proper file reference. This should link directly to the LICENSE file.
🔎 Proposed fix
-This project is licensed under the **Business Source License 1.1**. See [LICENSE.md](https://www.google.com/search?q=./LICENSE.md) for details.
+This project is licensed under the **Business Source License 1.1**. See [LICENSE.md](./LICENSE.md) for details.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| This project is licensed under the **Business Source License 1.1**. See [LICENSE.md](https://www.google.com/search?q=./LICENSE.md) for details. | |
| This project is licensed under the **Business Source License 1.1**. See [LICENSE.md](./LICENSE.md) for details. |
Fixes #722
Replaces the transaction executor with a regular RPC to send crank transactions.
Higher dimensional spaghetti as Babur calls it
Summary by CodeRabbit
New Features
Refactor
Documentation
Chores
✏️ Tip: You can customize this high-level summary in your review settings.