Conversation
|
deploy staging |
src/utils/parse_utils.ts
Outdated
| }, | ||
| ]); | ||
| } | ||
| return { |
There was a problem hiding this comment.
just to confirm here @steveklebanoff we shouldn't be making any check for intentOnFilling right? I partially remember our discussion and wanted to confirm :)
There was a problem hiding this comment.
i think it'd be nice to confirm intentOnFilling if they are hitting /quote but we'd have to make sure this doesn't trigger if they hit /price (switch on endpoint) -- that being said, this is just a 'nice to have' feature
There was a problem hiding this comment.
Per convo, let's do it
| "includedSources": { | ||
| "type": "string" | ||
| }, | ||
| "apiKey": { |
There was a problem hiding this comment.
curious, why is apiKey a GET parameter here?
There was a problem hiding this comment.
good call -- perhaps this is a mistake?
steveklebanoff
left a comment
There was a problem hiding this comment.
Awesome work! I'm impressed you did this so quickly
src/handlers/swap_handlers.ts
Outdated
| ); | ||
|
|
||
| const affiliateAddress = req.query.affiliateAddress as string; | ||
| const rfqt: Partial<RfqtRequestOpts> = |
There was a problem hiding this comment.
thanks for adding this typing!
| "includedSources": { | ||
| "type": "string" | ||
| }, | ||
| "apiKey": { |
There was a problem hiding this comment.
good call -- perhaps this is a mistake?
src/handlers/swap_handlers.ts
Outdated
| // tslint:disable-next-line: boolean-naming | ||
| const { excludedSources, nativeExclusivelyRFQT } = parseUtils.parseRequestForExcludedSources( | ||
| { | ||
| excludedSources: req.query.excludedSources as string, |
There was a problem hiding this comment.
I think it's the case that excludedSources can be undefined? If so :as string | undefined
| } | ||
|
|
||
| /** | ||
| * This constant contains, as keys, all ERC20BridgeSource types except from `Native`. |
There was a problem hiding this comment.
Great documentation, thank you
src/utils/parse_utils.ts
Outdated
|
|
||
| import { AvailableRateLimiter, DatabaseKeysUsedForRateLimiter, RollingLimiterIntervalUnit } from './rate-limiters'; | ||
|
|
||
| interface SwapRequestParams { |
There was a problem hiding this comment.
IMHO this name is too generic and could be confusing in the future. That being said, I can't think of a great name for this.
This is leading me to believe that it may be better to just send in these as regular parameters instead of introducing an object to hold them. What do you think?
There was a problem hiding this comment.
ParseRequestForExcludedSourcesParams
| throw new ValidationError([ | ||
| { | ||
| field: '0x-api-key', | ||
| code: ValidationErrorCodes.IncorrectFormat, |
There was a problem hiding this comment.
I feel like these are not quite 'IncorrectFormat's -- as the format is correct but the value is invalid.
What do you think about introducing FieldValueInvalid as a ValidationErrorCode instead of a reason? Then we could add InvalidApiKey as a reason
There was a problem hiding this comment.
code: FieldInvalid
reason: Invalid API key
src/errors.ts
Outdated
| PercentageOutOfRange = 'MUST_BE_LESS_THAN_OR_EQUAL_TO_ONE', | ||
| ConflictingFilteringArguments = 'CONFLICTING_FILTERING_ARGUMENTS', | ||
| ArgumentNotYetSupported = 'ARGUMENT_NOT_YET_SUPPORTED', | ||
| FieldInvalid = 'FieldInvalid', |
There was a problem hiding this comment.
FieldInvalid seems more like a ValidationErrorCode to me than a ValidationErrorReason
src/types.ts
Outdated
| intentOnFilling?: boolean; | ||
| isIndicative?: boolean; | ||
| }; | ||
| rfqt?: Partial<RfqtRequestOpts>; |
There was a problem hiding this comment.
I think we only want this to be intentOnFilling, isIndicative and nativeExclusivelyRFQT, not the other RfqtRequestOpts -- is that correct?
If so, use Pick instead of Partial
There was a problem hiding this comment.
Pick< RfqtRequestOpts , 'intentOnFilling' | ....>
|
|
||
| const SUITE_NAME = 'parseUtils'; | ||
|
|
||
| describe(SUITE_NAME, () => { |
| @@ -0,0 +1,101 @@ | |||
| import { ERC20BridgeSource } from '@0x/asset-swapper'; | |||
There was a problem hiding this comment.
it'd be nice to add to the RFQT integration tests, to show that indicative & firm quotes return as expect when specifying includedSources=RFQT
| InvalidOrder = 1007, | ||
| InternalError = 1008, | ||
| TokenNotSupported = 1009, | ||
| FieldInvalid = 1010, |
There was a problem hiding this comment.
src/utils/parse_utils.ts
Outdated
| throw new ValidationError([ | ||
| { | ||
| field: 'takerAddress', | ||
| code: ValidationErrorCodes.FieldInvalid, |
There was a problem hiding this comment.
Should this just be the RequiredField code?
src/utils/parse_utils.ts
Outdated
| throw new ValidationError([ | ||
| { | ||
| field: 'intentOnFilling', | ||
| code: ValidationErrorCodes.FieldInvalid, |
There was a problem hiding this comment.
Again - should this just be a RequiredField code?
# Conflicts: # src/handlers/swap_handlers.ts
|
deploy staging |
| } | ||
|
|
||
| // We enforce a valid API key - we don't want to fail silently. | ||
| if (request.apiKey === undefined) { |
There was a problem hiding this comment.
Thank you for distinguishing these!
| { | ||
| field: 'takerAddress', | ||
| code: ValidationErrorCodes.RequiredField, | ||
| reason: ValidationErrorReasons.TakerAddressInvalid, |
There was a problem hiding this comment.
Looking at this again, I think we could get rid of ValidationErrorReasons.TakerAddressInvalid
field: takerAddress, code: ValidationErrorCodes.RequiredField is descriptive enough.
EDIT: looks like reason is required, so perhaps we leave as-is
# [1.13.0](v1.12.0...v1.13.0) (2020-08-03) ### Bug Fixes * Kovan deploy UniswapV2 ([#304](#304)) ([f4fb99b](f4fb99b)) * Kovan ERC20BridgeSampler ([#299](#299)) ([56f7a90](56f7a90)) ### Features * added a unique identifier to the quote within the timestamp metadata … ([#281](#281)) ([d992563](d992563)) * Rfqt included ([#293](#293)) ([965dedb](965dedb))
|
🎉 This PR is included in version 1.13.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |

Description
Adds a new parameter
includedSources=RFQTwhich allows a requestor to solely request RFQT liquidity from the order salad. As of now, the implementation ofincludedSourcesexclusively permits RFQT but it can be extended in the future will full backwards-compatibility for our integrators.Testing Instructions
Checklist
[WIP]if necessary.