Identify the application that raised the warning and preserve its exact text. Determine whether it blocked a new request, reported a position-stacking restriction or identified an actual second broker order. No universal native Rithmic “duplicate-order warning” text was verified. Do not dismiss or bypass a message on the assumption that it means only one thing.
Educational software guidance. Trading involves risk. Read the financial and information disclaimers.
Check the warning's scope
| Question | Why it matters |
|---|---|
| Which application produced it? | Chart, bridge and broker messages can differ |
| Was a request accepted or rejected? | A warning is not proof of a broker fill |
| Are there distinct broker orders? | Similar rows may be statuses or partial executions |
| Was repeated delivery recorded? | One trigger can have multiple transport attempts |
| Is adding to a position permitted/configured? | Stacking is different from duplicate delivery |
Use the current error information from that actual interface. This article does not fabricate an error screenshot or an exact provider string.
Investigate before retrying
- Preserve the message, application version, timestamp and account context.
- Check the receiving-service record and any broker response.
- Reconcile current position and working orders.
- Compare alert-event streams and delivery attempts.
- Ask the provider/service about the specific restriction when its meaning remains unclear.
TradingView documents conditional resubmission for certain server responses. Its Pine guide also distinguishes multiple event sources. These are possible investigation branches, not proof of a root cause in your account.
Do not bypass a restriction by guessing
Changing quantity, adding another alert or disabling a stacking control can alter the requested exposure without correcting the initial problem. PickMyTrade's published duplicate-position field is not proof of universal delivery deduplication. Follow its current generated workflow and preserve the record of what was blocked or accepted.
If orders may exist, confirm them before any manual action. The duplicate-order guide gives the complete timeline method. No order, cancellation or duplicate-setting change was performed here.
Common questions
Does the warning mean a second trade already filled?
Not necessarily. Determine the recorded broker outcome separately.
Does every Rithmic client use the same warning?
No universal wording or native control was established. Identify the actual issuer of the message.
Should I delete one of two similar history rows?
History rows are evidence, not automatically extra working orders. Reconcile their identities and events first.
Can a resend be safe because the alert triggered only once?
One trigger can have multiple transport attempts under the documented conditions. Verify recipient and broker handling before another send.