Conversation
- Queue submitting offers to the blockchain from stripe payments — Includes a UI for viewing queue items - Uses redis via bull, but can fall back to not using any queue. Part of issue #16
DanielVF
changed the title
mikeshultz
left a comment
mikeshultz
left a comment
There was a problem hiding this comment.
LGTM. Minor commentary inline.
Unfortunately, I’ve not been able to get an end-to-end shop running locally with Stripe. I’ve tested this PR by using the stripe webhook tool, and overriding the data that is passed from stripe in the webhook route. I’ve seen the queue items being created and processing started, but it’s not end to tested.
For future reference, they have a handy docker container you can use for sandbox testing:
docker run --rm -it stripe/stripe-cli --api-key "sk_test_XXXXxxxXXXX" listen -jf https://localhost:3000/webhook --skip-verify
| .catch(err => { | ||
| console.log(err) | ||
| }) | ||
| { attempts: 6 } |
There was a problem hiding this comment.
I wanted to give it a longer time window to try over. Other than that, it's arbitrary.
There was a problem hiding this comment.
Not a dealbreakr or antyhing, but you could configure backoff too.
| * job.data should have {shopId, amount, encryptedData} | ||
| * @param {*} job | ||
| */ | ||
| async function processor(job) { |
There was a problem hiding this comment.
Might recommend using job.progress to show completion. It can sometimes help with troubleshooting, though perhaps job.log takes care of that here.
|
It turns out that the Bull v4 API is different from v3. I think the UI also only works with v3 when you use the alpha build. Probably easiest to just downgrade to v3 for now? |
|
Moved back to bull 3, and this thing is actually tested now! Give it a whir. |
4 participants
When a user makes a Stripe payment, we now enqueue the work of creating an offer and submitting it to the blockchain.
This PR uses the bull queue package, which is backed by redis. It seems to have a good API for this, doesn’t try to do too much, and has a lot of built in error handling.
It is great to be able to run our stack without external dependencies, so I’ve written a fallback queue class that is used if redis is not configured. In this case, we skip the queue, and instead process queue items as soon as they are added.
I’ve added bull-board UI to /super-admin/queue
In the future, we'll want to also queue up the actions that run on the listener side. I wanted to get this PR live first to verify our approach, and get our education before adding those. Those should be very quick.