The contract uses Clock::get().unwrap().unix_timestamp.try_into().unwrap()
to fetch the current timestamp. Although the intent is for the transaction to fail on error, using unwrap() results in a program panic, making it harder to diagnose issues.
Code Location:
Issue: The use of .unwrap() can lead to a panic, which is less informative than a controlled program error. It also results in the transaction failing with a generic error code rather than a domain-specific one.
Impact
Poor Error Reporting: Panics return generic errors, complicating debugging and auditing.
Compute Budget Waste: Panics consume very high compute units, which is inefficient.
Manual review of error handling patterns
Knowledge of Anchor best practices
Use proper error propagation with ? to return a specific error code while still ensuring transaction failure.
Explanation:
Clock::get()? safely retrieves the current timestamp.
.try_into().map_err(|_| ErrorCode::CalculationOverflow)? ensures that conversion failures are caught and reported with a specific error code.
It is very unlikely `Clock::get` to fail, therefore I think it is safe to use `unwrap` here. Consider this issue as informational.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.