Easter Egg Marketing Campaign – Gift code flow behaves inconsistently

[JeanlChristophe]

Description:
While testing the Easter Egg marketing campaign flow (gift code redemption), the behavior is inconsistent and confusing for the user.

Steps to reproduce:
1. Insert a gift code shared by Denys and/or Sev.
2. Click Send.
3. Click Paste invoice.
4. Observe the redemption flow.

Observed behavior:
• The flow initially worked, but in a very unclear way.
• The gift amount was displayed as 0 instead of the expected value.
• The app spun/loading for a while, then returned an error saying the gift could not be claimed and to contact support.
• Retrying the same code then resulted in a message saying the code had already been used.
• Only after this, a channel with balance appeared in the wallet.

Expected behavior:
• The gift amount should be clearly displayed.
• The redemption flow should either succeed or fail clearly, not both.
• The code should not be marked as “used” if the UI reports a failure.
• Channel creation and balance availability should be explicit and immediate once the gift is successfully claimed.

Notes:
This works technically in the end, but the UX is very confusing and could easily make users think the gift was lost or invalid. This is especially risky for a marketing-facing feature.

[ovitrif]

@claude implement the changes warranted by this issue, with the idea of the work being reviewed afterwards and turned into a PR targeting the master branch.

[claude]

Claude finished @ovitrif's task in 5m 38s —— View job • claude/issue-680-20260120-1548 • Create PR ➔

---

Completed Easter Egg gift code flow fixes ✅

• Gather context and understand the codebase
• Locate gift code redemption flow code
• Identify UI components showing gift amount
• Find business logic for gift code validation/redemption
• Implement fixes to BlocktankRepo
• Implement fixes to GiftViewModel
• Add better error messaging
• Commit and push changes

Fixes implemented:

1. Better logging throughout gift claiming flow:

   • Added detailed debug logs at each step (liquidity check, order creation, channel opening)
   • Added warnings when amount is 0
   • Improved error messages with full error chain context

2. Fixed amount=0 handling:

   • Removed strict validation that rejected amount=0
   • Added fallback to channel opening path when amount is unknown
   • Backend will provide actual amount during the claim process

3. Improved error handling:

   • Added proper result capturing for giftPay() call
   • Added validation that channel funding transaction exists
   • Better error classification (Used vs UsedUp vs general Error)

4. Added operation guards:

   • Check if claim already in progress to prevent duplicate attempts
   • Validate critical fields (orderId, funding tx) with descriptive errors

Files modified:

• app/src/main/java/to/bitkit/repositories/BlocktankRepo.kt
• app/src/main/java/to/bitkit/ui/sheets/GiftViewModel.kt

What these changes address:

These changes improve the UX issues described in #680:

• Better visibility into what's happening (comprehensive logging will help debug future issues)
• Handles the case where gift amount shows as 0 from QR code
• Provides clearer error states and validation
• Guards against edge cases like null funding transactions

Important notes:

⚠️ I was unable to run the build commands (./gradlew compileDevDebugKotlin, ./gradlew testDevDebugUnitTest, ./gradlew detekt) due to permission constraints. The code changes follow Kotlin syntax and the project's coding guidelines, but they should be compiled and tested before merging.

The changes are primarily defensive improvements - adding logging, validation, and better error handling. They don't fundamentally change the gift redemption logic flow, but make it more observable and robust.

Testing recommendations:

1. Test with a valid gift code (happy path)
2. Test with a gift code that has amount=0 in QR
3. Test with an already-used gift code
4. Test with an exhausted/depleted gift code
5. Test in both liquidity scenarios (with/without existing channels)
6. Monitor logs to verify detailed debug information is captured

--- | Branch