Confirm whether there are two distinct broker orders, then compare the alert events, deliveries and receiving-service requests that preceded them. Similar display rows can represent different stages or partial fills. Avoid resending, canceling or changing duplicate-position settings before establishing the actual account state and event timeline.
Educational software guidance. Trading involves risk. Read the financial and information disclaimers.
Build the event timeline
| Layer | Evidence |
|---|---|
| Script/alert | Event source, alert identity and trigger time |
| Delivery | Each webhook attempt and response |
| Recipient | Each accepted/rejected message and generated request |
| Broker | Distinct order identities, status and fills |
| Account | Current position and remaining working orders |
Keep private identifiers in the account investigation; redact them from public examples. Use Order History and Fill History to distinguish order events from execution records.
Check possible causes without assuming one
- Determine whether two separately active alerts carry the same intended trade.
- Check whether both strategy order-fill and
alert()streams actually triggered with trade messages. - Check multiple-account routing and quantity scaling; intentional account requests are not automatically duplicates.
- Compare transport attempts with recipient and broker records before attributing a resend.
- Separate partial fills or status updates for one order from two distinct orders.
TradingView's alert documentation explains the separate event streams. Selecting both does not necessarily double every trade; the actual script and messages matter.
TradingView can resend certain deliveries
The official resubmission rule covers HTTP 500–599 responses except 504, with resends after five seconds and up to four sends per trigger. This is transport behavior. It does not prove duplicate broker orders in a particular incident or certify the recipient's deduplication.
A position-stacking switch is not a delivery guarantee
PickMyTrade's JSON reference includes a duplicate-position option. Do not rename that option into a universal event-id/idempotency guarantee or assume turning it off resolves every duplicate entry. Use current generator instructions and investigate actual requests.
No duplicate incident was induced or account setting changed for this guide. It provides a reconciliation method, not a certified root cause for a particular account.
What to give support
Provide the redacted timeline, relevant timestamps/timezones, event types, connection/account context and recorded outcomes. Ask it to explain the recipient's actual handling of repeated delivery for the affected version/workflow. Do not blindly cancel one of two rows from an article's example.
Common questions
Do two fills prove two duplicate orders?
No. One order can have partial executions. Reconcile order identity, quantity and status.
Does TradingView retry every error?
No. The documented resubmission rule has specific response conditions. Do not broaden it to every timeout or failure.
Does disabling duplicate positions prove idempotency?
No. Position-stacking behavior and handling the same delivery twice are different questions.
Should I resend when the broker outcome is unknown?
First reconcile the account/order record or use the provider's supported investigation process.