-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: sync pisp/master to v11.10.1 #237
Conversation
…int_env_name Renamed ALS_ENDPOINT_HOST to ALS_ENDPOINT
* Initial commit for bulk transfers support * Initial commit for bulk quotes and bulkt transfers support * Complete inbound API bulk quotes implementation * Separate bulk quotes switch base URL * Add postTransfers and getBulkTransfers * Update Outbound API spec with bulk transfers endpoints * Update outbound API spec * Add outbound bulk transfers * Fix API spec bugs * Add bulk party lookup * Whitespace fixes * Add outbound bulk quotes requests * Remove used imports * Add outbound POST bulk transfers handler * Add outboud GET /bulkTransfers/{ID} * Add Jest config for test debugging * Add unit tests for bulk quotes and bulk transfers * Add tests for outbound API. Fix missing specs entries. * Add tests for outbound API /bulkQuotes abd /bulkTransfers * Add inbound GET /bulkQuotes/{ID} * Add unit tests for inbound GET bulkQuotesById, PUT bulkQuotesById, PUT bulkQuotesErrorById * Fix spec description for /bulkTransfers and variable initialization in InboundTransfersModel * Remove unreferenced spec entry. * Updates per code review * Updates per code review * Updates per code review * Add more unit tests for InboundTransfersModel. Mor code review changes * Remodel bulk quotes using single state state-machine pattern * Remodel bulk transfers using state machine pattern. Add GET bulk quotes endpoint * Update API spec * Fix tests * Add more unit tests for InboundTransfersModel * Add unit tests for OutboundBulkQuotesModel * Add tests for OutboundBulkTransfersModel * Fix linting issue * PR review updates. * Remove some IDE auto inserted whitespaces * PR review update Co-authored-by: Sam <10507686+elnyry-sam-k@users.noreply.github.com>
#1386: Bug fixes
…feature/#1462-request-for-notif
* requests now respond with .data instead of .body * Fixed test. Fixed (not in the broken sense, but sort of) package version.
…feature/#1462-request-for-notif
Do not JSON parse already-parsed response data
…n in test mode. Tidied up websocket server creation. Removed koa-websocket and added ws.
#1386: Update sdk-standard-component
…ver-constructor Refactored OAuth test server constructor
…ndard-components-functionality Incorporated new sdk-standard-components functionality into SDK
Run all tests
Log request retries
…e-env-vars Remove redundant example env vars
fixed config refactoring issue
* Added GET /quotes{ID} * added the error callback * update readme
…pe}/{ID}/{SubId}/error (mojaloop#233) * Added GET /quotes{ID} * added PUT /participants * merge master * delete accidentally added files
Valentin seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
// where this event is fired but only if env ENABLE_PISP_MODE=true | ||
subId = await cache.subscribe(channel, async (channel, message, sid) => { | ||
try { | ||
try { | ||
const parsed = JSON.parse(message); | ||
this.context.data = { | ||
...parsed, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@eoln is this supposed to be ...parsed
or ...parsed.data
?
It doesn't line up with the test found at
const message = { |
expect(model.context.data).toEqual({ |
I'm not sure how we want to store the message or if it's the test that's faulty. It's creating a false positive since the expect(...)
is run after an asyncronyous function. (Which is an issue of itself, feel like that was discussed at one point)
I vote we follow up on this maybe in a different PR since it's a little out of context for this merge ticket.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice finding @kleyow
themessage
is published to the channel here:
await ctx.state.cache.publish(authorizationChannel, { |
so model.context.data
will store the whole published message and request payload body will be model.context.data.data
but here we are expecting this.context.data
to be the request payload
const { data, logger } = this.context; |
so you are right there should be `...parsed.data``` in L140
but why the test is false positive.... ?
for this test important is how cache.publish
called here:
await cache.publish(channel, JSON.stringify(message)); |
is mocked:
publish: jest.fn(async (channel, message) => await handler(channel, message, subId)), |
so the expect
in L167 is called when handler
is called what we check L178 & L188 and thanks to await
everything should be synchronous here.... but there is then
in L155 which could be executed after the L192
if you move block L156-174 after L188 the test should properly fail and prove I am right... (if you don't fix ...parsed.data
before ;-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kleyow I suggest fixing this false positive test in separate PR, at the end of merging with the latest master
branch. If there will be no time, or there will be unexpected complications, please create a separate story ticket to expose this hidden work.
// where this event is fired but only if env ENABLE_PISP_MODE=true | ||
subId = await cache.subscribe(channel, async (channel, message, sid) => { | ||
try { | ||
try { | ||
const parsed = JSON.parse(message); | ||
this.context.data = { | ||
...parsed, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice finding @kleyow
themessage
is published to the channel here:
await ctx.state.cache.publish(authorizationChannel, { |
so model.context.data
will store the whole published message and request payload body will be model.context.data.data
but here we are expecting this.context.data
to be the request payload
const { data, logger } = this.context; |
so you are right there should be `...parsed.data``` in L140
but why the test is false positive.... ?
for this test important is how cache.publish
called here:
await cache.publish(channel, JSON.stringify(message)); |
is mocked:
publish: jest.fn(async (channel, message) => await handler(channel, message, subId)), |
so the expect
in L167 is called when handler
is called what we check L178 & L188 and thanks to await
everything should be synchronous here.... but there is then
in L155 which could be executed after the L192
if you move block L156-174 after L188 the test should properly fail and prove I am right... (if you don't fix ...parsed.data
before ;-)
Will do. |
No description provided.