getting same order from openrelay api always using 0xproject/connect api about openrelay HOT 3 CLOSED

Here's what's happening:

0x Connect isn't looking for an object with {"OrderRequestOpts": {...}, "PagedRequestOpts": {...}}, it's looking for am object with the properties of an OrderRequestOpts object and a PagedRequestOpts object. Using your example above, you'd want:

{
  "exchangeContractAddress": "0x479cc461fecd078f766ecc58533d6f69580cf3ac",
  "maker": "0xe60c537190939913291db1296a8758b654519e46",
  "makerTokenAddress": "0xa8e9fa8f91e5ae138c74648c9c304f1c75003a8d",
  "taker": "0x0000000000000000000000000000000000000000",
  "takerTokenAddress": "0xc778417e063141139fce010982780140aa0cd5ab",
  "tokenAddress": "0xa8e9fa8f91e5ae138c74648c9c304f1c75003a8d",
  "trader": "0xe60c537190939913291db1296a8758b654519e46",
  "page": 1,
  "perPage": 100
}

Note that rather than a blank feeRecipient, I left the feeRecipient out entirely, as if it is present 0x Connect expects it to match the regular expression of an Ethereum address.

I'd also note that the above order returns an empty list [] - OpenRelay has no orders that match your query.

Broadly speaking, you only need to add fields to your OrdersRequestOpts when you want to filter on them. Generally you wouldn't set all three of "maker", "taker", and "trader, as "trader" means "Either the maker or the taker matches this value". Likewise, you wouldn't set all three of "makerTokenAddress", "takerTokenAddress", and "tokenAddress", as "tokenAddress" means "Either the makerTokenAddress or the takerTokenAddress matches this value."

I would probably reduce your filter down to:

{
  "exchangeContractAddress": "0x479cc461fecd078f766ecc58533d6f69580cf3ac",
  "makerTokenAddress": "0xa8e9fa8f91e5ae138c74648c9c304f1c75003a8d",
  "taker": "0x0000000000000000000000000000000000000000",
  "takerTokenAddress": "0xc778417e063141139fce010982780140aa0cd5ab",
  "page": 1,
  "perPage": 100
}

Which ensures that you're filtering for orders on Ropsten, where the makerTokenAddress is a particular token, the takerTokenAddress is a particular token, and anybody can take the order (this is currently superfluous on OpenRelay, as we only allow orders that anyone can take, but that will change in the near future, so it's best to leave that in).

Note that this will still get you an empty list of orders, as we don't have any orders for that token pair (OpenRelay's order volume is currently quite small, even on Ropsten).

I'm closing this for now, as it's not an issue with OpenRelay, but I'm happy to continue the discussion if you have further questions.

from openrelay.

from openrelay.

submitOrderAsync() returns a promise for a JSON object returned in the content of the HTTP request made by 0x Connect. This HTTP request doesn't return anything other than a status code, so the content would be empty. If it had gotten an error status code, the promise would have thrown an error (you'd get it with promise.catch() instead of promise.then()). So as far as the HTTP service is concerned, your order was accepted.

However, in responding to the initial request, OpenRelay only validates details that can be validated upon a simple inspection of the order. It considers things like:

• Is the JSON well formed?
• Are the signatures valid?
• Are the fees adequate?
• Is the fee recipient valid?
• Is the exchange address valid?

There are other details that require communication with an Ethereum RPC server to determine:

• Has the order been filled or cancelled?
• Does the maker have enough tokens to fill the order and pay the fees?
• Has the maker set allowances to allow the ZRX token proxy contract to trade this token on their behalf?

Because the Ethereum RPC server is a bit fragile, we don't do those validations during the HTTP request. Instead we queue those orders for further validation and validate them after the HTTP response, but before they get listed in the order book. It's worth noting that we also track those attributes continuously, and if any of them should ever cease to be valid we will remove an order from the orderbook. For this reason, I would recommend using zeroEx.exchange.validateOrderFillableOrThrowAsync to test that your orders are fillable before submitting them to OpenRelay, as it will give you more detailed information about why your order may not make it into the orderbook.

In your case, I looked at the maker address on Etherscan: https://ropsten.etherscan.io/address/0xe60c537190939913291db1296a8758b654519e46

I see that you have approved transfers for Ropsten ZRX (the fee token and maker token), but that you don't actually hold any ZRX. As a result, your order is being invalidated before it gets listed in the orderbook.

You can create WETH using zeroEx.etherToken.depositAsync, set the proper allowances for that, then OpenRelay has at least one order on the orderbook offering ZRX in exchange for WETH. If you fill that order (at least partially), you should then have the necessary tokens to submit the order you're trying to fill.

from openrelay.