[Queenode]

Summary

This pull request addresses and resolves all 4 issues assigned to @Queenode:

• test: cover get_token #71: test: cover get_token
• test: cover a tipper who is also a recipient #70: test: cover a tipper who is also a recipient
• create_jar never extends the new jar's storage lifetime #67: create_jar never extends the new jar's storage lifetime
• Add a troubleshooting section for common invoke failures #61: Add a troubleshooting section for common invoke failures

---

Detailed Changes

1. Cover get_token view (Closes #71)

• Added get_token_returns_constructor_token test in contracts/tip-splitter/src/test.rs mirroring the existing get_admin_returns_constructor_admin test to verify get_token() matches the token address supplied at constructor initialization.

2. Cover tipper who is also a recipient (Closes #70)

• Added tip_tipper_holding_non_final_share_preserves_all_balances covering the tipper holding a non-final split share in a jar.
• Added tip_tipper_holding_final_share_preserves_all_balances covering the tipper holding the final split share.
• Both tests verify that self-transfers are cleanly skipped, no-op funds stay in the tipper's wallet, other recipients receive their exact share without unintended dust absorption, and every balance (including the tipper's and contract's) is explicitly asserted.

3. Extend storage lifetime on jar creation (Closes #67)

• Updated create_jar in contracts/tip-splitter/src/lib.rs to call env.storage().persistent().extend_ttl(&key, JAR_TTL_THRESHOLD, JAR_TTL_LEDGERS) upon creating a new jar entry, aligning it with all other operations (update_splits, transfer_jar_ownership, tip, get_jar).
• Reused existing constants JAR_TTL_THRESHOLD and JAR_TTL_LEDGERS.
• Added regression test freshly_created_jar_extends_ttl_and_survives_ledger_advance asserting that a freshly created jar survives ledger advances past network default lifetimes, and updated touched_jar_survives_a_ledger_advance_that_archives_an_idle_one to match the new initial TTL.

4. Add Troubleshooting guide for common invoke failures (Closes #61)

• Added a ## Troubleshooting section to docs/CONTRACT.md describing common invoke and client errors that do not map to contract error codes:
  1. Missing WebAssembly target during build (wasm32-unknown-unknown) and fix (rustup target add wasm32-unknown-unknown).
  2. Recipient without a trustline for the token (HostError: Error(Contract, #1) / op_no_trustline) and fix (establishing SAC trustline or claiming held escrow).
  3. Unfunded source account (HostError: Error(Storage, MissingValue) / txNO_ACCOUNT) and fix (funding with reserve via Friendbot or transfer).
  4. Jar slug format or missing registration (InvalidJarId / JarNotFound) and fix (verifying format with leading @ and checking registration).

---

Closes #71
Closes #70
Closes #67
Closes #61

[drips-wave]

@Queenode Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits