feat: read any wallet's order-book positions and collateral#125
Conversation
|
Warning Review limit reached
More reviews will be available in 25 minutes and 7 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses rolling per-developer review limits. Reviews become available again as older review attempts age out of the rolling limit window. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughTwo new wallet-parameterized query functions— ChangesWallet-parameterized portfolio queries
Estimated code review effort🎯 2 (Simple) | ⏱️ ~15 minutes Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 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 |
Time Submission Status
Submit or update total time with: Add time on top of previous submission with: See available commands to help comply with our Guidelines. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
examples/maa_lifecycle_example/main.py (1)
56-83: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueConsider adding sub-second precision to salt generation for improved uniqueness.
The fresh-salt-per-run approach using
int(time.time()).to_bytes(8, "big")works well for most scenarios, but running the script twice within the same second will produce identical salts and collide. While this is acceptable for a smoke test, you could make it more robust with sub-second precision:♻️ Optional improvement for salt uniqueness
- SALT = b"MAA" + int(time.time()).to_bytes(8, "big") + b"\x00" * 21 # 3 + 8 + 21 = 32 bytes + # Use microsecond precision for sub-second uniqueness + timestamp_us = int(time.time() * 1_000_000) + SALT = b"MAA" + timestamp_us.to_bytes(8, "big") + b"\x00" * 21 # 3 + 8 + 21 = 32 bytesAlternatively, use
os.urandom(32)for cryptographically random salts, though timestamp-based salts are easier to reason about for debugging.🤖 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 `@examples/maa_lifecycle_example/main.py` around lines 56 - 83, The salt generation using int(time.time()).to_bytes(8, "big") only captures second-level precision, which means running the script twice within the same second will produce identical salts and cause collisions. Improve the salt uniqueness by modifying the timestamp-based salt generation to include sub-second precision. Instead of using int(time.time()) which truncates to seconds, multiply time.time() by a factor (such as 1000000 for microsecond precision) or use time.time_ns() for nanosecond precision to ensure each run within the same second gets a unique salt value. Verify the resulting bytes fit within the 8-byte constraint used in the SALT construction.
🤖 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.
Nitpick comments:
In `@examples/maa_lifecycle_example/main.py`:
- Around line 56-83: The salt generation using int(time.time()).to_bytes(8,
"big") only captures second-level precision, which means running the script
twice within the same second will produce identical salts and cause collisions.
Improve the salt uniqueness by modifying the timestamp-based salt generation to
include sub-second precision. Instead of using int(time.time()) which truncates
to seconds, multiply time.time() by a factor (such as 1000000 for microsecond
precision) or use time.time_ns() for nanosecond precision to ensure each run
within the same second gets a unique salt value. Verify the resulting bytes fit
within the 8-byte constraint used in the SALT construction.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 9e6abbcc-741f-4053-b716-ad90137f066b
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
📒 Files selected for processing (7)
bindings/bindings.goexamples/maa_lifecycle_example/.env.exampleexamples/maa_lifecycle_example/README.mdexamples/maa_lifecycle_example/main.pygo.modsrc/trufnetwork_sdk_py/client.pytests/test_portfolio_by_wallet.py
|
@holdex pr submit-time 3h |
1 participant
resolves: https://github.com/truflation/website/issues/4171
What
Read a wallet's order-book portfolio by address from Python, plus a working demonstration in the MAA lifecycle example:
TNClient.get_positions_by_wallet(wallet_address)— holdings + open ordersTNClient.get_collateral_by_wallet(wallet_address, bridge)— total locked collateral on a bridgeWhy
get_user_positions/get_user_collateralread the signer (@caller), so they cannot read a wallet you do not sign for — e.g. an owner, or a delegated market-maker bot, watching an agent wallet (MAA) whose positions live under the MAA's participant id, not the signer's. These wrap the new node action and sdk-go methods.How
GetPositionsByWallet/GetCollateralByWallet) forwarding to sdk-go, plus thinTNClientwrappers that JSON-parse the result and reuse the existingUserPosition/UserCollateraltypes.sdk-goto the merged commit that adds the methods (go.mod/go.sum);kwil-dbis unchanged.Example
examples/maa_lifecycle_examplenow:.env(zero-dependency loader; real env vars still win), with a committed.env.exampleMAA_SALTpins it)Testing
tests/test_portfolio_by_wallet.py— pure unit tests (monkeypatched binding) for argument forwarding, JSON parsing, and empty handling. All pass.Depends on (merged)
Context
Summary by CodeRabbit
New Features
get_positions_by_wallet()retrieves positions and holdings for any wallet address, whileget_collateral_by_wallet()returns collateral data without requiring the wallet signer.Documentation
Tests