Fix writable account failure logs#22
Conversation
WalkthroughThis PR updates access permission validation to emit two specific log messages when an ChangesInvalidWritableAccount Error Logging
🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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 |
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
svm/src/access_permissions.rs (1)
212-224: 🧹 Nitpick | 🔵 Trivial | ⚡ Quick winConsider adding log message assertions for consistency.
This test also triggers
InvalidWritableAccount(likeprivileged_payer_rejects_non_magic_write), but doesn't verify the log messages. Adding similar assertions would improve test coverage consistency and help catch regressions in the logging behavior.📋 Suggested addition
assert_eq!( tx.execution_details.status, Err(TransactionError::InvalidWritableAccount) ); + assert_eq!( + tx.execution_details.log_messages.as_ref().unwrap(), + &vec![ + format!( + "Program log: Account 1: {writable} was illegally used as writable" + ), + "Program Magic11111111111111111111111111111111111111 failed: InvalidWritableAccount" + .to_string(), + ] + ); }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@svm/src/access_permissions.rs` around lines 212 - 224, The test privileged_payer_rejects_unlisted_magic_instruction currently asserts the error but omits log assertions; update this test to also verify the transaction's logged messages (the same log assertions used in privileged_payer_rejects_non_magic_write) so we validate the logging behavior alongside tx.execution_details.status (check the transaction's execution_details logs/log_messages for the expected rejection message). Locate privileged_payer_rejects_unlisted_magic_instruction and mirror the log-message assertions from privileged_payer_rejects_non_magic_write to ensure consistent coverage.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@svm/src/access_permissions.rs`:
- Line 66: The log string currently says "writeable" which is inconsistent with
the error type InvalidWritableAccount; update the message literal "Program log:
Account {i}: {offender} was illegally used as writeable" to use "writable"
instead, and update the corresponding test assertion (referenced around line
203) so it expects "writable" as well; search for the exact message and the test
assertion to change both occurrences together.
- Around line 68-71: Replace the two hardcoded Magic program failure log strings
with a formatted string using the existing MAGIC_PROGRAM_ID constant (e.g.,
format!("Program {} failed: InvalidWritableAccount", MAGIC_PROGRAM_ID)) wherever
logs.push(...) currently uses the long "Program Magic1111... failed:
InvalidWritableAccount" literal in access_permissions.rs, and update the
corresponding test assertions to expect the formatted string using
MAGIC_PROGRAM_ID instead of the hardcoded literal; locate occurrences by
searching for the literal text and the logs.push call in this file and its tests
and swap them to use MAGIC_PROGRAM_ID via format!.
---
Outside diff comments:
In `@svm/src/access_permissions.rs`:
- Around line 212-224: The test
privileged_payer_rejects_unlisted_magic_instruction currently asserts the error
but omits log assertions; update this test to also verify the transaction's
logged messages (the same log assertions used in
privileged_payer_rejects_non_magic_write) so we validate the logging behavior
alongside tx.execution_details.status (check the transaction's execution_details
logs/log_messages for the expected rejection message). Locate
privileged_payer_rejects_unlisted_magic_instruction and mirror the log-message
assertions from privileged_payer_rejects_non_magic_write to ensure consistent
coverage.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: df51d488-e711-432b-b836-ee852277fe9f
📒 Files selected for processing (1)
svm/src/access_permissions.rs
There was a problem hiding this comment.
♻️ Duplicate comments (2)
svm/src/access_permissions.rs (2)
68-71: 🧹 Nitpick | 🔵 Trivial | ⚡ Quick winReplace the hardcoded Magic program failure log with
MAGIC_PROGRAM_ID.The hardcoded base58 string should be replaced with the
MAGIC_PROGRAM_IDconstant for maintainability.♻️ Proposed refactor
- logs.push( - "Program Magic11111111111111111111111111111111111111 failed: InvalidWritableAccount" - .to_string(), - ); + logs.push(format!( + "Program {MAGIC_PROGRAM_ID} failed: InvalidWritableAccount" + ));🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@svm/src/access_permissions.rs` around lines 68 - 71, Replace the hardcoded base58 program id string in the logs.push call with the MAGIC_PROGRAM_ID constant: locate the push that builds the "Program ... failed: InvalidWritableAccount" message in svm::access_permissions (the logs variable and its push invocation) and construct the message using the MAGIC_PROGRAM_ID constant (e.g., format the string with MAGIC_PROGRAM_ID or MAGIC_PROGRAM_ID.to_string()) so the log becomes "Program {MAGIC_PROGRAM_ID} failed: InvalidWritableAccount" instead of the literal base58 string.
205-207: 🧹 Nitpick | 🔵 Trivial | ⚡ Quick winReplace the hardcoded Magic program ID in test assertion with
MAGIC_PROGRAM_ID.The test assertion should use the
MAGIC_PROGRAM_IDconstant instead of the hardcoded base58 string.♻️ Proposed refactor
- "Program Magic11111111111111111111111111111111111111 failed: InvalidWritableAccount" - .to_string(), + format!("Program {MAGIC_PROGRAM_ID} failed: InvalidWritableAccount"),🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@svm/src/access_permissions.rs` around lines 205 - 207, The test assertion currently hardcodes the Magic program base58 string; update the assertion to use the MAGIC_PROGRAM_ID constant instead (e.g., interpolate or format MAGIC_PROGRAM_ID into the expected error string) so it reads "Program {MAGIC_PROGRAM_ID} failed: InvalidWritableAccount" rather than the literal "Magic1111..." string; modify the assertion that constructs the expected error message to reference MAGIC_PROGRAM_ID (and call to_string() or format! as needed) so the test stays correct if the constant changes.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Duplicate comments:
In `@svm/src/access_permissions.rs`:
- Around line 68-71: Replace the hardcoded base58 program id string in the
logs.push call with the MAGIC_PROGRAM_ID constant: locate the push that builds
the "Program ... failed: InvalidWritableAccount" message in
svm::access_permissions (the logs variable and its push invocation) and
construct the message using the MAGIC_PROGRAM_ID constant (e.g., format the
string with MAGIC_PROGRAM_ID or MAGIC_PROGRAM_ID.to_string()) so the log becomes
"Program {MAGIC_PROGRAM_ID} failed: InvalidWritableAccount" instead of the
literal base58 string.
- Around line 205-207: The test assertion currently hardcodes the Magic program
base58 string; update the assertion to use the MAGIC_PROGRAM_ID constant instead
(e.g., interpolate or format MAGIC_PROGRAM_ID into the expected error string) so
it reads "Program {MAGIC_PROGRAM_ID} failed: InvalidWritableAccount" rather than
the literal "Magic1111..." string; modify the assertion that constructs the
expected error message to reference MAGIC_PROGRAM_ID (and call to_string() or
format! as needed) so the test stays correct if the constant changes.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: c4de9c20-d435-4446-b036-d81a60b48695
📒 Files selected for processing (1)
svm/src/access_permissions.rs
Summary
InvalidWritableAccountprogram failure log for writable-account access violations (explorer and SDKs otherwise incorrectly show this txs as succesful)Summary by CodeRabbit
Bug Fixes
Tests