fix(limits): book Edit preserves orderId and enables price-only update (#312) #791
No reviewers
Labels
No labels
agent:fix_bugfix
agent:fix_conflicts
agent:fix_security
agent:gap_analysis
agent:implement
agent:implement
agent:implement
agent:open_issues
agent:ready
agent:research
agent:security_audit
agent:verify
architecture
backend
blocker:hybrid
blocker:launch
blocker:limit-orders
blocker:v2
block:log_only
block:security
bug
ci
contracts
correctness
deploy
dev
devops
docs
documentation
duplicate
e2e
enhancement
epic
feature
frontend
functional-completion
gas
good first issue
governance
help wanted
high-risk
hooks
hybrid
indexer
infra
infrastructure
integrators
invalid
launch-blocker
limit-orders
localnet
localterra
low priority
missing-implementation
needs-design
ops
performance
priority
high
priority
medium
product
qa
QA
question
ready
ready
research
scripts
security
security-hardening
smartcontracts
tech-debt
testing
ux
UX
v2
verification
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
code/cl8y-dex-terraclassic!791
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "cursor/gitlab-issue-workflow-cb0d"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Fixes https://gitlab.com/PlasticDigits/cl8y-dex-terraclassic/-/work_items/312 (follow-up to #294).
The
/limitspage droppedorderIdwhen prefilling from the order book Edit action, so submit always calledplace_limit_orderand created duplicate resting orders. This mirrors the existing/tradeticket flow:buildLimitBookEditContext(draft)on book prefill (includesorderId,expiresAt,hintAfterOrderId)UpdateLimitOrderPriceviauseLimitOrderUpdatePriceMutationLIMIT_EDIT_NON_PRICE_CHANGE_MESSAGE)Acceptance checklist
/limitsprefill shows “Editing order #N”npm run test -- src/pages/LimitOrdersPage.test.tsx— book Edit prefills ticket with orderIdUpdateLimitOrderPrice, notplace_limit_orderorderIdpreserved through prefill; no duplicate on price amendupdateLimitOrderPricecalled with order id7; edit context shows#7orderIdLimitOrdersPage.test.tsx(4 new cases)make test-frontendgreenmake test-frontend(832 tests)/limitsbook Edit → price amend → single order id on LCDVerification for third parties
Manual (LocalTerra): open
/limits→ select pair → Edit own book row → change price only → Update price → confirm sameorder_idon LCD/indexer.Files touched
frontend-dapp/src/pages/LimitOrdersPage.tsx— edit context + update-price submit pathfrontend-dapp/src/pages/LimitOrdersPage.test.tsx— regression testsReference implementation unchanged:
TradeOrderTicket.tsx,limitOrderPriceEdit.ts.changed the description
changed the description
mentioned in issue #312
changed the description
Security review
Commit reviewed:
0a1810e9591052d74565187abe5ebcb415e3e542Scope:
frontend-dapp/src/pages/LimitOrdersPage.tsx,frontend-dapp/src/pages/LimitOrdersPage.test.tsx— mirrors existing/tradelimit-order edit flow (buildLimitBookEditContext,isPriceOnlyLimitEdit,useLimitOrderUpdatePriceMutation) onto/limits.Outcome:
FINDINGS: 0medium+Analysis
orderIdforUpdateLimitOrderPricecomes only from book Edit on rows whereorder.owner === walletAddress(OrderBookPanel). On-chainexecute_update_limit_order_priceenforceso.owner == info.sender→Unauthorizedotherwise. UI state tampering cannot amend another user's order.editContextis set,placeLimitCombinedOkrequires!editContext; non–price-only field changes seteditNonPriceChangedand disable submit. Aligns withTradeOrderTicket.tsx.orderIdrendered as a React number node;pricevalidated by existing place gates and contractDecimalchecks. No new HTML sinks or dynamic code paths.Prior MR security threads: none to re-report.
Inline threads: none (no medium+ findings).
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is ON. A cloud agent has been kicked off to fix the reported issue.
Reviewed by Cursor Bugbot for commit
0a1810e959. Configure here.Edit prefill omits expiry sync
Medium Severity
Book Edit stores the order’s
expiresAtineditContextbutonPrefillLimitTicketFromBooknever updates the form’sexpiresAt.isPriceOnlyLimitEditandeditNonPriceChangedcompare those values, so a stale ticket expiry can block “Update price” or show a false non-price change even when only price was edited.Reviewed by Cursor Bugbot for commit
0a1810e959. Configure here.added 1 commit
f9b5b828- fix: sync expiresAt when prefill limit edit from order bookCompare with previous version
changed the description
resolved all threads
Security review
Commit reviewed:
f9b5b8287f9d52c9ab91edd0d62b92baddbc22f2Scope:
frontend-dapp/src/pages/LimitOrdersPage.tsx,frontend-dapp/src/pages/LimitOrdersPage.test.tsx— mirrors existing/tradelimit-order edit flow (buildLimitBookEditContext,isPriceOnlyLimitEdit,useLimitOrderUpdatePriceMutation) onto/limits. Includes follow-up commit syncingexpiresAton book Edit prefill.Outcome:
FINDINGS: 0medium+Analysis
orderIdforUpdateLimitOrderPriceis set only via book Edit on rows whereorder.owner === walletAddress(OrderBookPanel). On-chainexecute_update_limit_order_priceenforceso.owner == info.sender→Unauthorizedotherwise. Client-sideeditContexttampering cannot amend another user's order.editContextis set,placeLimitCombinedOkrequires!editContext; non–price-only field changes seteditNonPriceChangedand disable submit. Aligns withTradeOrderTicket.tsx.orderIdrendered as a React number node;pricevalidated by existing place gates and contractDecimalchecks. No new HTML sinks or dynamic code paths.UpdateLimitOrderPricealso callsassert_not_paused. New test asserts Edit disabled when paused.Prior threads
0a1810e(FINDINGS: 0) — still applies; no new attack surface inf9b5b82(addssetExpiresAt(draft.expiresAt ?? null)so edit gating compares against the resting order).expiresAtsync was a functional/UX defect (blocked price update or false non-price guard), not an authz or fund-loss path; resolved inf9b5b82. Not re-reported as a security finding.Inline threads: none (no medium+ findings).
mentioned in commit
13422e60c4