It seems the code

engine.mergeOrders("label", order, order)

does something weird while nothing is expecting.

What do you mean by "wierd"?

Initial position doubles in Historical Tester:

Isn't that a 'normal behavior'? When you merge 2 orders with amount 0.001, the resulting merged order's amount will be 0.002 (aka the sum of the merged orders' amounts).

Read the first post: two orders are the same one. You can see the same label 'initial' of merged orders on the screenshot.

The mergeOrders method must do nothing in a such case.

Oh, I see now.

Hi, Support Team!

Do you confirm this bug?

NOT A BUG in my personal view.

This is Order Submission and Execution. Labels are for your own benefit.

The merge method doesn't care about Labels, it will merge Orders explicitly given to its parameters.
It is simply required to determine underlying Instruments and order sizes and reconcile all.
If programmer wants to use a 1 lot base order and merge it 10 times to produce a 10 lot position, that's his/her call and perogative.

The method takes a VARIABLE parameter list. The programmer provides that list.

Is it the responsibility of the programmer or the method implementer to sanitize the list?

Should the cost of checking for sloppy programming and a bad list be built into the method for all to bare or be left with those who are not operating with the appropriate care?
If I give the method a list of 10 orders, where order 6 and order 10 match (in terms of Label or Object Reference) that's some search needed to discover that during processing - on top of the existing Order field, state and Instrument checks.

Be sure that you could not repeat this "BUG" using the Platform, since the programmers of the platform have managed their side of the mergeOrders() contract before making their calls.

It's a utility method. It should be used correctly and intuitively. If you ask a merger method to merge 10 1 Lot orders (remember Labels mean nothing here, only order sizes, instrument and order state) then you implicitly ask the merger to interpret its 10 identical parameters as 10 individual and existing orders for consideration. This is reasonable and still consistent with say creating 10 1 Lot orders and merging those.

Depending on the underlying implementation and as per the method contract it will either work or throw an exception as soon as one of the underlying orders is found not to be in FILL state.

I do see and appreciate a strict interpretation of merge/existing(orders) but I care more about underlying performance and state/range checking costs.

If Support consider it a bug then it is what it is.

It's a bug for sure 'cause the mergeOrders method must not change net position by contract. See more Merge Positions:

For a public API it is the responsibility of the API developers to check the parameters for validity.



So, Support Team, what's up?

The issue has been registered.

Fixed with JForex-API 2.9.10.

Yes, it throws an exception now:

com.dukascopy.api.JFException: Cannot merge orders in state other than FILLED

But is such an exception appropriate for this case when an order is FILLED for sure?

Try:

    @Override
    public void onStart(IContext context) throws JFException {
        engine = context.getEngine();
        history = context.getHistory();
        console = context.getConsole();
        context.setSubscribedInstruments(new HashSet<Instrument>(Arrays.asList(instrument)), true);
        IOrder order = engine.submitOrder("market_" + System.currentTimeMillis(), instrument, OrderCommand.BUY, 1);
        order.waitForUpdate(IOrder.State.FILLED);
        engine.mergeOrders("merged_" + System.currentTimeMillis(), order, order);
    }

We get the following message: