feat: repeat token claim as long as there are outstanding tokens

[lklimek]

Problem to solve

When an user clicks "claim" and have a big amount of credits to claim that is above Platform's limits for single claim operation, only part of awaiting tokens is claimed. The user is not notified that there are more tokens available to claim.

Solution

Claim is repeated as long as there are outstanding tokens waiting to be claimed.

Copilot's summary

This pull request introduces a new feature to handle token claims more effectively and includes improvements to error handling and logging. The main changes involve adding a new claim_all_tokens method, updating the success result type to include token claim amounts, and enhancing the user interface to display token claim results.

Token Claim Enhancements:

• Added a new claim_all_tokens method in AppContext to handle multiple token claims in a loop until no more claims are available. This method returns the total number of tokens claimed. (src/backend_task/tokens/claim_tokens.rs, [1] [2]
• Updated the BackendTaskSuccessResult enum to include a TokensClaimed(TokenAmount) variant for reporting the number of tokens claimed. (src/backend_task/mod.rs, src/backend_task/mod.rsR102)
• Modified the existing claim_token method to return the TokensClaimed result with the claimed amount instead of a generic message. (src/backend_task/tokens/claim_tokens.rs, src/backend_task/tokens/claim_tokens.rsL123-R196)

Error Handling and Logging Improvements:

• Replaced eprintln! calls with structured logging using tracing::error! for better error reporting when updating token balances. (src/backend_task/tokens/claim_tokens.rs, [1] [2]
• Enhanced error handling in the token claim process to log protocol and consensus errors more effectively. (src/backend_task/tokens/claim_tokens.rs, [1] [2]

User Interface Updates:

• Added a display_task_result method to the ClaimTokensScreen to show success or error messages based on the token claim results. This includes displaying the number of tokens claimed or an error message if no tokens are available. (src/ui/tokens/claim_tokens_screen.rs, src/ui/tokens/claim_tokens_screen.rsR251-R269)

These changes improve the robustness of the token claim process and provide better feedback to users.

Summary by CodeRabbit

• New Features

  • "Claim all" option to bulk-claim tokens from the UI with a confirmation popup
  • Displays the total claimed amount and clearer success/error statuses
  • Streamlined wallet-unlock flow for claiming tokens

• Bug Fixes / Improvements

  • Background claiming now iterates until rewards are exhausted, with improved error logging and handling for partial claims

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

---

📝 Walkthrough

Walkthrough

Adds a new TokensClaimed(TokenAmount) success variant, implements single and repeated token-claim workflows (claim_token and claim_all_tokens), updates task routing for a claim_all flag, refactors the Claim Tokens UI (confirmation, wallet unlock, claim-all checkbox), and adds a DB helper to insert remote identities if missing.

Changes

Cohort / File(s)	Summary
Backend success enum & task entry src/backend_task/mod.rs	Appended TokensClaimed(TokenAmount) to BackendTaskSuccessResult.
Token claiming logic src/backend_task/tokens/claim_tokens.rs	Replaced claim_tokens with claim_all_tokens (looping multi-claim), added claim_token for single claims, changed error types to dash_sdk::Error, return TokensClaimed(total) and improved tracing/logging.
Token task handler src/backend_task/tokens/mod.rs	Added claim_all: bool to TokenTask::ClaimTokens; routes to claim_all_tokens or claim_token and adds nuanced ConsensusError/StateError matching.
Database identities src/database/identities.rs	Added pub fn insert_remote_identity_if_not_exists(...) to conditionally insert remote identity rows after existence check.
UI — Claim Tokens screen src/ui/tokens/claim_tokens_screen.rs	Replaced local confirmation with window popup; removed advanced-options UI; added claim_all checkbox and claimed_amount tracking; integrated wallet unlock via ScreenWithWalletUnlock; updated task-result handling and error display.

Sequence Diagram(s)

sequenceDiagram
    participant UI as ClaimTokensScreen
    participant Handler as TokenTaskHandler
    participant ClaimLogic as Claiming Logic
    participant DBBalance as Balance/State Update

    rect rgba(100, 150, 200, 0.5)
    note over UI,Handler: Single-claim flow (claim_all = false)
    UI->>Handler: dispatch TokenTask::ClaimTokens{claim_all:false}
    Handler->>ClaimLogic: call claim_token()
    ClaimLogic->>DBBalance: update balance/state with claimed_amount
    ClaimLogic-->>Handler: TokensClaimed(amount)
    Handler-->>UI: success result
    UI->>UI: set claimed_amount, status Complete
    end

    rect rgba(150, 100, 200, 0.5)
    note over UI,ClaimLogic: Bulk-claim flow (claim_all = true)
    UI->>Handler: dispatch TokenTask::ClaimTokens{claim_all:true}
    Handler->>ClaimLogic: call claim_all_tokens()
    loop until exhausted or no rewards
        ClaimLogic->>ClaimLogic: call claim_token() internally
        ClaimLogic->>DBBalance: update balance/state incrementally
        ClaimLogic->>ClaimLogic: aggregate total_claimed
    end
    ClaimLogic-->>Handler: TokensClaimed(total_claimed)
    Handler-->>UI: success result
    UI->>UI: set claimed_amount, status Complete
    end

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Poem

🐰 I nibble claims, one hop, then all,
A checkbox tick, a windowed call,
Balances hum and numbers climb,
Identities saved in quiet time,
The rabbit cheers: claims done — sublime! 🎉

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely summarizes the main change: implementing repeated token claims until all outstanding tokens are exhausted.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/claim-multiple

---

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

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[Copilot]

Pull Request Overview

This PR implements a feature to execute all available token claims when a user clicks "claim" to handle situations where the platform limits prevent claiming all tokens in a single operation. The solution continuously executes claims until no more tokens are available, ensuring users can claim their full token balance.

Key changes:

• Added a new claim_all_tokens method that iterates through all available claims
• Enhanced error handling and logging with structured tracing instead of println statements
• Updated the UI to display the total number of tokens claimed

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

File	Description
src/backend_task/tokens/claim_tokens.rs	Implements new claim_all_tokens method and improves error handling with structured logging
src/backend_task/mod.rs	Adds TokensClaimed variant to success result enum
src/backend_task/tokens/mod.rs	Updates call to use new claim_all_tokens method
src/ui/tokens/claim_tokens_screen.rs	Adds UI handling for displaying token claim results

[QuantumExplorer]

Sometimes we don't want to make all claims. We should give the user the option to do so or not.

[lklimek]

@copilot please take over this PR, merge v1.0-dev into it, and add a checkbox "Claim all" that will control if we will repeat token claim or not, enabled by default.

[Copilot]

@lklimek I've opened a new pull request, #545, to work on those changes. Once the pull request is ready, I'll request review from you.

[coderabbitai]

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)

src/backend_task/tokens/claim_tokens.rs (1)

140-184: ⚠️ Potential issue | 🟡 Minor

Add warning logs when document parsing fails or token_id is unavailable.

Lines 140–184 silently return claimed_amount = 0 when data_contract.token_id(token_position) is None or the claim result document lacks claimerId/amount fields. Since claim_all_tokens breaks its loop on TokensClaimed(0) (line 52), this causes on-chain successful claims to be silently discarded without retry or user notification.

Log a warning when the token_id is absent or expected document fields are missing, so claim successes aren't lost to schema changes or unexpected document structures.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/backend_task/tokens/claim_tokens.rs` around lines 140 - 184, The code
currently drops to returning TokensClaimed(0) silently if
data_contract.token_id(token_position) is None or the claim document lacks
expected fields; add warning logs to surface these cases: log a warning when
data_contract.token_id(token_position) returns None (include token_position and
any data_contract identifier/context available), and inside both
ClaimResult::Document and ClaimResult::GroupActionWithDocument branches, when
the (claimerId, amount) pattern match fails or the types are not
Value::Identifier/Value::U64, emit a tracing::warn with the document and
token_position; also log a warning if Identifier::from_bytes returns Err
(include the raw bytes and token_id) before continuing, keeping the existing
tracing::error on insert_token_identity_balance failures. This uses the existing
symbols token_id, token_position, ClaimResult::Document,
ClaimResult::GroupActionWithDocument, Identifier::from_bytes,
insert_token_identity_balance and ensures claim_all_tokens won't silently drop
successful claims without a warning.

🧹 Nitpick comments (2)

src/database/identities.rs (1)

139-144: TOCTOU: check-then-insert without a single atomic statement.

The SELECT COUNT and INSERT are two separate statements. Even after fixing the deadlock (using conn.execute), a concurrent thread could insert the same identity between the check and the insert, causing a constraint violation or duplicate. Consider using INSERT OR IGNORE (or INSERT ... ON CONFLICT DO NOTHING) to make this atomic, which also simplifies the code by removing the SELECT entirely.

♻️ Proposed simplification using INSERT OR IGNORE

-        // Check if the identity already exists
-        let conn = self.conn.lock().unwrap();
-        let mut stmt =
-            conn.prepare("SELECT COUNT(*) FROM identity WHERE id = ? AND network = ?")?;
-        let count: i64 = stmt.query_row(params![id, network], |row| row.get(0))?;
-
-        // If the identity doesn't exist, insert it
-        if count == 0 {
-            self.execute(
-                "INSERT INTO identity (id, data, is_local, alias, identity_type, network)
-             VALUES (?, ?, 0, ?, ?, ?)",
-                params![id, data, alias, identity_type, network],
-            )?;
-        }
+        let conn = self.conn.lock().unwrap();
+        conn.execute(
+            "INSERT OR IGNORE INTO identity (id, data, is_local, alias, identity_type, network)
+             VALUES (?, ?, 0, ?, ?, ?)",
+            params![id, data, alias, identity_type, network],
+        )?;

This also eliminates the deadlock issue from the previous comment. As per coding guidelines, SQLite uses a single connection wrapped in Mutex<Connection>, so the INSERT OR IGNORE approach is safe and idiomatic.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/database/identities.rs` around lines 139 - 144, The current logic does a
separate SELECT COUNT followed by self.execute INSERT which is TOCTOU-prone;
replace the check-then-insert with a single atomic statement such as "INSERT OR
IGNORE" (or "INSERT ... ON CONFLICT DO NOTHING") so the insert is no-op if the
identity exists, remove the SELECT COUNT path entirely, and handle the execute
result from the INSERT OR IGNORE in the same function (use the existing
self.execute call site in identities.rs where the insert currently occurs) to
avoid deadlocks and duplicate constraint errors.

src/backend_task/tokens/claim_tokens.rs (1)

38-80: Unbounded loop — consider adding a safety limit.

The loop relies on the platform eventually returning zero or a consensus error to terminate. If something unexpected happens (e.g., a bug where the claimed amount never reaches zero, or transient network issues that cause partial success states), this could loop indefinitely. A max-iteration safety guard would improve robustness.

💡 Suggested safety guard

     let mut total_claimed = 0;
+    const MAX_CLAIM_ITERATIONS: usize = 10_000;
+    let mut iterations = 0;
     loop {
+        iterations += 1;
+        if iterations > MAX_CLAIM_ITERATIONS {
+            return Err(format!(
+                "Exceeded maximum claim iterations ({}); claimed so far: {}",
+                MAX_CLAIM_ITERATIONS, total_claimed
+            ));
+        }
         let result = self
             .claim_token(

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/backend_task/tokens/claim_tokens.rs` around lines 38 - 80, Add a bounded
safety guard to the unbounded loop that repeatedly calls self.claim_token:
introduce a max attempts constant (e.g., MAX_CLAIM_ITERATIONS) or an attempts
counter and increment it each iteration, break and return an Err if the limit is
exceeded (including total_claimed in the error), and optionally back off briefly
between retries; update the loop surrounding self.claim_token(...) that inspects
BackendTaskSuccessResult::TokensClaimed and the consensus error path to use this
bounded loop (tracking attempts alongside total_claimed) so the function cannot
loop indefinitely.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/backend_task/mod.rs`:
- Around line 221-222: Remove the dead enum variant ClaimedTokens(FeeResult)
from the backend task enum definition (leave TokensClaimed(TokenAmount) as-is),
and delete any now-unused imports or type references tied to FeeResult; ensure
no pattern matches or constructors reference ClaimedTokens (search for
ClaimedTokens and remove or refactor them) and run tests/build to confirm
nothing else depends on it.

In `@src/database/identities.rs`:
- Around line 133-144: The code holds self.conn.lock() (conn guard) and then
calls self.execute(...), which deadlocks because self.execute also locks
self.conn; replace the call to self.execute inside the guarded section with a
direct call on the local connection (e.g., use conn.execute(...) or
conn.prepare(...).execute(...) with the same SQL and params![id, data, alias,
identity_type, network]) so the insert runs using the existing guard instead of
attempting to re-lock self.conn; ensure you remove/self-contained the
transaction on the conn guard and keep parameter order identical.

In `@src/ui/tokens/claim_tokens_screen.rs`:
- Around line 209-223: The code calls selected_key.clone().expect("No key
selected") inside the TokenTask::ClaimTokens construction which can panic if
self.selected_key is None; before building the action (or before user
confirmation handler) check self.selected_key and handle the None case instead
of unwrapping — e.g., disable the Confirm path when self.selected_key.is_none(),
or return/emit a user-facing error/log and do not set action; specifically
change the logic around selected_key.clone().expect(...) in the ClaimTokens
creation (and the surrounding confirmation handler that assigns action) to
early-return or set an error state when selected_key is None so no panic occurs.
- Around line 247-251: The displayed claimed_amount is in base units and must be
adjusted by the token decimals before rendering; update the UI code that
currently labels "Amount claimed: {} tokens" to convert self.claimed_amount
(u64) to a decimal token amount using the token decimal info from
self.token_configuration.conventions().decimals(), reusing the same
conversion/formatting logic used by token_decimal_multiplier() in
direct_token_purchase_screen.rs (or extract that helper into a shared function),
and then show the formatted human-readable amount (e.g., dividing by 10^decimals
and formatting to a suitable precision) instead of the raw u64 value.

---

Outside diff comments:
In `@src/backend_task/tokens/claim_tokens.rs`:
- Around line 140-184: The code currently drops to returning TokensClaimed(0)
silently if data_contract.token_id(token_position) is None or the claim document
lacks expected fields; add warning logs to surface these cases: log a warning
when data_contract.token_id(token_position) returns None (include token_position
and any data_contract identifier/context available), and inside both
ClaimResult::Document and ClaimResult::GroupActionWithDocument branches, when
the (claimerId, amount) pattern match fails or the types are not
Value::Identifier/Value::U64, emit a tracing::warn with the document and
token_position; also log a warning if Identifier::from_bytes returns Err
(include the raw bytes and token_id) before continuing, keeping the existing
tracing::error on insert_token_identity_balance failures. This uses the existing
symbols token_id, token_position, ClaimResult::Document,
ClaimResult::GroupActionWithDocument, Identifier::from_bytes,
insert_token_identity_balance and ensures claim_all_tokens won't silently drop
successful claims without a warning.

---

Nitpick comments:
In `@src/backend_task/tokens/claim_tokens.rs`:
- Around line 38-80: Add a bounded safety guard to the unbounded loop that
repeatedly calls self.claim_token: introduce a max attempts constant (e.g.,
MAX_CLAIM_ITERATIONS) or an attempts counter and increment it each iteration,
break and return an Err if the limit is exceeded (including total_claimed in the
error), and optionally back off briefly between retries; update the loop
surrounding self.claim_token(...) that inspects
BackendTaskSuccessResult::TokensClaimed and the consensus error path to use this
bounded loop (tracking attempts alongside total_claimed) so the function cannot
loop indefinitely.

In `@src/database/identities.rs`:
- Around line 139-144: The current logic does a separate SELECT COUNT followed
by self.execute INSERT which is TOCTOU-prone; replace the check-then-insert with
a single atomic statement such as "INSERT OR IGNORE" (or "INSERT ... ON CONFLICT
DO NOTHING") so the insert is no-op if the identity exists, remove the SELECT
COUNT path entirely, and handle the execute result from the INSERT OR IGNORE in
the same function (use the existing self.execute call site in identities.rs
where the insert currently occurs) to avoid deadlocks and duplicate constraint
errors.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check if ClaimedTokens (the old variant) is still referenced anywhere
echo "=== Usages of ClaimedTokens ==="
rg -n --type=rust '\bClaimedTokens\b' -C2

echo ""
echo "=== Usages of TokensClaimed ==="
rg -n --type=rust '\bTokensClaimed\b' -C2

Repository: dashpay/dash-evo-tool

Length of output: 3259

---

Remove unused ClaimedTokens(FeeResult) variant.

The ClaimedTokens variant is dead code—it's defined but never used anywhere in the codebase. The active variant is TokensClaimed(TokenAmount), which is returned in claim_tokens.rs and matched in claim_tokens_screen.rs. Since they serve different semantic purposes (fee tracking vs. amount tracking), remove ClaimedTokens entirely rather than renaming.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/backend_task/mod.rs` around lines 221 - 222, Remove the dead enum variant
ClaimedTokens(FeeResult) from the backend task enum definition (leave
TokensClaimed(TokenAmount) as-is), and delete any now-unused imports or type
references tied to FeeResult; ensure no pattern matches or constructors
reference ClaimedTokens (search for ClaimedTokens and remove or refactor them)
and run tests/build to confirm nothing else depends on it.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

rg -n "fn execute" src/database/identities.rs -A 10

Repository: dashpay/dash-evo-tool

Length of output: 47

---

🏁 Script executed:

# Find the Database struct and impl block
rg -n "impl.*Database|struct Database" src/database/ -A 5 --type rust

Repository: dashpay/dash-evo-tool

Length of output: 7347

---

🏁 Script executed:

# Look at the full context of the method in question
sed -n '117,148p' src/database/identities.rs

Repository: dashpay/dash-evo-tool

Length of output: 1362

---

🏁 Script executed:

# Check other methods that use self.execute() to see if they also lock conn first
rg -n "self\.execute|self\.conn\.lock" src/database/identities.rs --type rust -B 2 -A 2

Repository: dashpay/dash-evo-tool

Length of output: 4126

---

🏁 Script executed:

rg -n "fn execute\(" src/database/ --type rust -A 15 | head -60

Repository: dashpay/dash-evo-tool

Length of output: 47

---

🏁 Script executed:

# Specifically look in mod.rs for the execute method
cat src/database/mod.rs

Repository: dashpay/dash-evo-tool

Length of output: 4348

---

🏁 Script executed:

# Verify the proposed fix works by checking similar patterns in the codebase
# Look for methods that lock conn, then use conn.execute() directly
rg -n "let conn = self.conn.lock" src/database/identities.rs -A 10 | grep -E "(conn\.execute|conn\.prepare)"

Repository: dashpay/dash-evo-tool

Length of output: 583

---

🏁 Script executed:

# Check if 'status' column has a default or is NOT NULL in the schema
rg -n "CREATE TABLE.*identity" src/database/ -A 20 --type rust

Repository: dashpay/dash-evo-tool

Length of output: 4501

---

Critical deadlock: self.execute() called while holding self.conn lock.

Line 133 acquires self.conn.lock(). The guard remains in scope through the end of the function. When self.execute() is called on line 140, it internally attempts to lock self.conn again (see mod.rs lines 39–41). Rust's Mutex is not reentrant, causing a deadlock on the same thread.

Use conn.execute() directly instead, consistent with other methods that hold the lock (e.g., set_identity_alias, delete_local_qualified_identity).

🐛 Proposed fix: use local connection guard for the INSERT

         // If the identity doesn't exist, insert it
         if count == 0 {
-            self.execute(
+            conn.execute(
                 "INSERT INTO identity (id, data, is_local, alias, identity_type, network)
              VALUES (?, ?, 0, ?, ?, ?)",
                 params![id, data, alias, identity_type, network],
             )?;
         }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/database/identities.rs` around lines 133 - 144, The code holds
self.conn.lock() (conn guard) and then calls self.execute(...), which deadlocks
because self.execute also locks self.conn; replace the call to self.execute
inside the guarded section with a direct call on the local connection (e.g., use
conn.execute(...) or conn.prepare(...).execute(...) with the same SQL and
params![id, data, alias, identity_type, network]) so the insert runs using the
existing guard instead of attempting to re-lock self.conn; ensure you
remove/self-contained the transaction on the conn guard and keep parameter order
identical.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Potential panic on Line 216: .expect("No key selected").

If self.selected_key is None when the user confirms, this will panic. Although the UI flow typically ensures a key is selected, a defensive check would be safer — either disable the Confirm button when no key is selected or handle the None case gracefully.

💡 Suggested fix

-                    action = AppAction::BackendTasks(
-                        vec![
-                            BackendTask::TokenTask(Box::new(TokenTask::ClaimTokens {
-                                data_contract: Arc::new(self.token_contract.contract.clone()),
-                                token_position: self.identity_token_basic_info.token_position,
-                                actor_identity: self.identity.clone(),
-                                distribution_type,
-                                signing_key: self.selected_key.clone().expect("No key selected"),
-                                public_note: self.public_note.clone(),
-                                claim_all: self.claim_all,
-                            })),
-                            BackendTask::TokenTask(Box::new(TokenTask::QueryMyTokenBalances)),
-                        ],
-                        BackendTasksExecutionMode::Sequential,
-                    );
+                    if let Some(signing_key) = self.selected_key.clone() {
+                        action = AppAction::BackendTasks(
+                            vec![
+                                BackendTask::TokenTask(Box::new(TokenTask::ClaimTokens {
+                                    data_contract: Arc::new(self.token_contract.contract.clone()),
+                                    token_position: self.identity_token_basic_info.token_position,
+                                    actor_identity: self.identity.clone(),
+                                    distribution_type,
+                                    signing_key,
+                                    public_note: self.public_note.clone(),
+                                    claim_all: self.claim_all,
+                                })),
+                                BackendTask::TokenTask(Box::new(TokenTask::QueryMyTokenBalances)),
+                            ],
+                            BackendTasksExecutionMode::Sequential,
+                        );
+                    } else {
+                        self.status = ClaimTokensStatus::ErrorMessage(
+                            "No signing key selected.".to_string(),
+                        );
+                        self.show_confirmation_popup = false;
+                    }

📝 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.

Suggested change

	action = AppAction::BackendTasks(
	vec![
	BackendTask::TokenTask(Box::new(TokenTask::ClaimTokens {
	data_contract: Arc::new(self.token_contract.contract.clone()),
	token_position: self.identity_token_basic_info.token_position,
	actor_identity: self.identity.clone(),
	distribution_type,
	signing_key: self.selected_key.clone().expect("No key selected"),
	public_note: self.public_note.clone(),
	claim_all: self.claim_all,
	})),
	BackendTask::TokenTask(Box::new(TokenTask::QueryMyTokenBalances)),
	],
	BackendTasksExecutionMode::Sequential,
	);
	if let Some(signing_key) = self.selected_key.clone() {
	action = AppAction::BackendTasks(
	vec![
	BackendTask::TokenTask(Box::new(TokenTask::ClaimTokens {
	data_contract: Arc::new(self.token_contract.contract.clone()),
	token_position: self.identity_token_basic_info.token_position,
	actor_identity: self.identity.clone(),
	distribution_type,
	signing_key,
	public_note: self.public_note.clone(),
	claim_all: self.claim_all,
	})),
	BackendTask::TokenTask(Box::new(TokenTask::QueryMyTokenBalances)),
	],
	BackendTasksExecutionMode::Sequential,
	);
	} else {
	self.status = ClaimTokensStatus::ErrorMessage(
	"No signing key selected.".to_string(),
	);
	self.show_confirmation_popup = false;
	}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/tokens/claim_tokens_screen.rs` around lines 209 - 223, The code calls
selected_key.clone().expect("No key selected") inside the TokenTask::ClaimTokens
construction which can panic if self.selected_key is None; before building the
action (or before user confirmation handler) check self.selected_key and handle
the None case instead of unwrapping — e.g., disable the Confirm path when
self.selected_key.is_none(), or return/emit a user-facing error/log and do not
set action; specifically change the logic around
selected_key.clone().expect(...) in the ClaimTokens creation (and the
surrounding confirmation handler that assigns action) to early-return or set an
error state when selected_key is None so no panic occurs.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check how other screens display token amounts
rg -n --type=rust 'tokens.*amount|format.*token' -C3 --glob='!claim_tokens_screen.rs' | head -100

Repository: dashpay/dash-evo-tool

Length of output: 9171

---

🏁 Script executed:

#!/bin/bash
# Check for token formatting helpers
rg -n --type=rust 'fn.*format.*token|fn.*display.*amount|fn.*token.*decimal' | head -30

Repository: dashpay/dash-evo-tool

Length of output: 251

---

🏁 Script executed:

#!/bin/bash
# Check the TokenAmount type definition
rg -n --type=rust 'type TokenAmount|struct TokenAmount' | head -20

Repository: dashpay/dash-evo-tool

Length of output: 47

---

🏁 Script executed:

#!/bin/bash
# Check how claimed_amount is set and if there's any decimal conversion
rg -n --type=rust 'claimed_amount' -C5 | head -80

Repository: dashpay/dash-evo-tool

Length of output: 6596

---

🏁 Script executed:

#!/bin/bash
# Check if claim_tokens_screen.rs has decimal handling helpers
rg -n --type=rust 'fn.*decimal|token_configuration' src/ui/tokens/claim_tokens_screen.rs

Repository: dashpay/dash-evo-tool

Length of output: 516

---

🏁 Script executed:

#!/bin/bash
# Look at the full show_success_screen method and surrounding context
sed -n '237,260p' src/ui/tokens/claim_tokens_screen.rs

Repository: dashpay/dash-evo-tool

Length of output: 739

---

🏁 Script executed:

#!/bin/bash
# Check how direct_token_purchase_screen uses token_decimal_multiplier
rg -n -A5 'token_decimal_multiplier' src/ui/tokens/direct_token_purchase_screen.rs | head -40

Repository: dashpay/dash-evo-tool

Length of output: 1154

---

🏁 Script executed:

#!/bin/bash
# Check the structure of ClaimTokensScreen to see if it has token_configuration
sed -n '40,75p' src/ui/tokens/claim_tokens_screen.rs

Repository: dashpay/dash-evo-tool

Length of output: 1204

---

Display claimed amount accounting for token decimals.

claimed_amount is a raw u64 in base units from the blockchain response. Displaying it directly as "tokens" without adjusting for the token's decimal places will show misleading values to users (e.g., 100000000 tokens instead of 1 token if decimals=8). The token_configuration is available in the struct and has the required decimal information via .conventions().decimals(). Consider implementing a decimal adjustment similar to the token_decimal_multiplier() pattern used in direct_token_purchase_screen.rs.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/ui/tokens/claim_tokens_screen.rs` around lines 247 - 251, The displayed
claimed_amount is in base units and must be adjusted by the token decimals
before rendering; update the UI code that currently labels "Amount claimed: {}
tokens" to convert self.claimed_amount (u64) to a decimal token amount using the
token decimal info from self.token_configuration.conventions().decimals(),
reusing the same conversion/formatting logic used by token_decimal_multiplier()
in direct_token_purchase_screen.rs (or extract that helper into a shared
function), and then show the formatted human-readable amount (e.g., dividing by
10^decimals and formatting to a suitable precision) instead of the raw u64
value.

[PastaPastaPasta]

I think I'd rather we just claim the max amount, and show to the user they may need to claim again? It seems a bit strange and maybe error prone potentially.