pipedream
pipedream copied to clipboard
4057 waitwhile actions
I'm having issues testing the actions for this integration. The responses are not consistent between the API in Postman and the API from the Waitwhile documentation. Also, the TypeScript types for the API are not ready until version 5. The API uses the OpenAPI definition package 'api', which is still on version 4. I was able to test some of the actions, but became stagnant on the 'Retrieve-Customer' action. Here are the results of testing:
The latest updates on your projects. Learn more about Vercel for Git ↗︎
Name | Status | Preview | Updated |
---|---|---|---|
pipedream-docs | ✅ Ready (Inspect) | Visit Preview | Oct 17, 2022 at 5:00PM (UTC) |
pipedream-docs-redirect-do-not-edit | ✅ Ready (Inspect) | Visit Preview | Oct 17, 2022 at 5:00PM (UTC) |
Thank you so much for submitting this! We've added it to our backlog to review, and our team has been notified.
Thanks for submitting this PR! When we review PRs, we follow the Pipedream component guidelines. If you're not familiar, here's a quick checklist:
- [ ] Create components to address specific use cases whenever possible
- [ ] Component
key
s should follow the formatapp_name_slug-slugified-component-name
- [ ] Components should follow the standard directory structure
- [ ] Prefer Node.js client libraries to REST APIs
- [ ] When making API requests, handle pagination to ensure all data / events are processed
- [ ] Use
secret
props to capture sensitive data - [ ] Props and methods should be defined in app files whenever possible
- [ ] Document methods with JS Docs
- [ ] Use
optional
props whenever possible, and set adefault
value where you can - [ ] Use async options to accept user input wherever possible
- [ ] Create subscription webhooks sources (vs polling sources) whenever possible
- [ ] Always emit a
summary
with events - [ ] Use a built-in deduping strategy wherever possible
- [ ] When building webhook sources, follow these best practices
- [ ] When building polling sources, follow these best practices
Hi @ljdatasci, I noticed your linter automatically changed lots of files that are not related to waitwhile!
You can run npx eslint components/waitwhile --fix
to automatically fix some linting issues after discarding the unwanted changes in the other apps.
And regarding the checks errors:
- The
package.json
version needs to be revved -
waithwile-update-customer-note-entry
component key is misspelled
Hi @andrewjschuang I fixed the issue with the misspelled component key. I think I ran the linter on the wrong directory and I'm not exactly sure how to discard the changes. Are there any instructions on how to roll back the linter changes?
Hi @andrewjschuang I fixed the issue with the misspelled component key. I think I ran the linter on the wrong directory and I'm not exactly sure how to discard the changes. Are there any instructions on how to roll back the linter changes?
Can you try the following:
git revert 0717bd2123b156e8234fb2a0381a3a6565b03b4d
git revert d7a84d01c57c07d2b295cf9625e2ee5db6e266b4
npx pnpm i
git revert d7a84d01c57c07d2b295cf9625e2ee5db6e266b
I received errors: error: commit 0717bd2123b156e8234fb2a0381a3a6565b03b4d is a merge but no -m option was given. fatal: revert failed error: commit 0717bd2123b156e8234fb2a0381a3a6565b03b4d is a merge but no -m option was given. fatal: revert failed
I received errors: error: commit 0717bd2 is a merge but no -m option was given. fatal: revert failed error: commit 0717bd2 is a merge but no -m option was given. fatal: revert failed
Hmm, I might have been mistaken. The commands below will surely work in this specific case since I have tested them but in general I only recommend this approach if you know what you're doing:
git checkout -b checkpoint # create this branch to do everything in it
git reset --hard origin/4057-Waitwhile-Actions
git reset 658a3f9a
rm components/waitwhile/=7 # delete this file
git add components/waitwhile
git commit -m 'add waitwhile components'
git clean -fd
git rebase origin/master
npx pnpm i
git add pnpm-lock.yaml && git commit -m 'update pnpm-lock.yaml'
git push
If everything is correct, then you can run:
git checkout 4057-Waitwhile-Actions
git reset --hard origin/checkpoint
git push -f
When I ran git rebase origin/master I received these errors: error: cannot rebase: You have unstaged changes. error: Please commit or stash them.
When I ran git rebase origin/master I received these errors: error: cannot rebase: You have unstaged changes. error: Please commit or stash them.
Did you run git clean -fd
?
If you need to restart you can run git reset --hard origin/4057-Waitwhile-Actions
(considering you are in the checkpoint
branch)
git rebase origin/master
Yes, I'm in the checkpoint branch. I ran git clean -fd again and then git rebase origin/master, and I still get the same errors. I then started over with git reset --hard origin/4057-Waitwhile-Actions, reran the steps up to git rebase origin/master, and I still get the same error. VS Code Source control says I have 706 pending changes.
Yes, I'm in the checkpoint branch. I ran git clean -fd again and then git rebase origin/master, and I still get the same errors. I then started over with git reset --hard origin/4057-Waitwhile-Actions, reran the steps up to git rebase origin/master, and I still get the same error. VS Code Source control says I have 706 pending changes.
Can you also run git reset --hard HEAD
after git clean -fd
?
git add pnpm-lock.yaml && git commit -m 'update pnpm-lock.yaml'
That worked, but when I tried to push my changes with git push I received the message: To push the current branch and set the remote as upstream, use
git push --set-upstream origin checkpoint
That worked, but when I tried to push my changes with git push I received the message: To push the current branch and set the remote as upstream, use
git push --set-upstream origin checkpoint
Nice, I forgot to add that command. Yeah, go ahead and run that push command and I can take a look if everything is right
That worked, but when I tried to push my changes with git push I received the message: To push the current branch and set the remote as upstream, use
git push --set-upstream origin checkpoint
Nice, I forgot to add that command. Yeah, go ahead and run that push command and I can take a look if everything is right
Done.
Done.
Nice, now you can run:
git checkout 4057-Waitwhile-Actions
git reset --hard checkpoint
git push -f
git push -f
Done. Is someone going to QA these actions? I had issues with the Waitwhile API and had some errors that could not get more details from the Pipedream console.
I tried pushing my changes per above but received the error: ! [rejected] HEAD -> 4057-Waitwhile-Actions (non-fast-forward) error: failed to push some refs to 'https://github.com/ljdatasci/pipedream.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.
should I run these commands?
I tried pushing my changes per above but received the error: ! [rejected] HEAD -> 4057-Waitwhile-Actions (non-fast-forward) error: failed to push some refs to 'https://github.com/ljdatasci/pipedream.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.
should I run these commands?
Yes, you can run git pull
I tried pushing my changes per above but received the error: ! [rejected] HEAD -> 4057-Waitwhile-Actions (non-fast-forward) error: failed to push some refs to 'https://github.com/ljdatasci/pipedream.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. should I run these commands?
Yes, you can run
git pull
I can use async options for the customerId and the inviteId props, but they are used in several different functions. For example, customerId can be used in the retrieveCustomer, removeCustomer and listCustomerNoEntries functions the the waitwhile.app.ts file. Is there a way to add multiple functions to an async options?
I can use async options for the customerId and the inviteId props, but they are used in several different functions. For example, customerId can be used in the retrieveCustomer, removeCustomer and listCustomerNoEntries functions the the waitwhile.app.ts file. Is there a way to add multiple functions to an async options?
Yes, after creating the async options()
method for the prop in the app file, on the component you can use it just like it is already done by you.
// list-customer-note-entries.ts
props: {
waitwhile,
customerId: {
propDefinition: [
"customerId",
],
},
},
async run({ $ }) {
const data = await this.waitwhile.listCustomerNoteEntries(this.customerId);
$.export("summary", "Successfully retrieved customer note entries");
return data;a
}
But with the waitwhile actions, a prop would need more than one async function. For example, customerId can be used with listCustomersNotEntries, retrieveCustomer and removeCustomer. Can I add more than one function to the async options, like so:
customerId: { async options(opts) { return listCutomerNotEntries(opts) } async options(opts) { return retrieveCustomer(opts) }
async options(opts) { return removeCustomer(opts) } }
On Mon, Sep 26, 2022 at 12:17 PM Andrew Chuang @.***> wrote:
I can use async options for the customerId and the inviteId props, but they are used in several different functions. For example, customerId can be used in the retrieveCustomer, removeCustomer and listCustomerNoEntries functions the the waitwhile.app.ts file. Is there a way to add multiple functions to an async options?
Yes, after creating the async options() method for the prop in the app file, on the component you can use it just like it is already done by you.
// list-customer-note-entries.ts props: { waitwhile, customerId: { propDefinition: [ "customerId", ], },},async run({ $ }) { const data = await this.waitwhile.listCustomerNoteEntries(this.customerId); $.export("summary", "Successfully retrieved customer note entries"); return data;a}
— Reply to this email directly, view it on GitHub https://github.com/PipedreamHQ/pipedream/pull/4224#issuecomment-1258294473, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMO5IV3SPPSPR7PXXSTOUZLWAHEBPANCNFSM6AAAAAAQLZNYNM . You are receiving this because you were mentioned.Message ID: @.***>
I'm not sure I'm understanding you are trying to achieve, async options()
is a function that fetches a list of customers from the app, in this case, and displays a drop-down list for the user to select one.
If you find it easier, you can find me through our community Slack
I'm not sure I'm understanding you are trying to achieve,
async options()
is a function that fetches a list of customers from the app, in this case, and displays a drop-down list for the user to select one.If you find it easier, you can find me through our community Slack
I reviewed the API docs and the only way to get a list of customerIds would be to call the list-customers action and get the customerId from the step exports. There is no separate API call that can give you a list of customerIds. This is true for all other props for the waitwhile components. The user can get any of the action props by step exports in the Pipedream action and passing it to the next action the workflow.
I reviewed the API docs and the only way to get a list of customerIds would be to call the list-customers action and get the customerId from the step exports. There is no separate API call that can give you a list of customerIds. This is true for all other props for the waitwhile components. The user can get any of the action props by step exports in the Pipedream action and passing it to the next action the workflow.
Sorry, didn't see the notification for this comment. Below is an example for async options()
for customerId
. The other props can follow the same pattern. More info here.
customerId: {
label: "Customer ID",
type: "string",
description: "Identifier of customer, automatically derived from visitor contact information if not provided.",
async options({ prevContext }) {
const { prevEndAt } = prevContext; // get endAt from previous context
const {
endAt, // used for pagination, not tested
customers,
} = await this.listCustomers({ // use method implemented in methods below
startAfter: prevEndAt, // pagination
});
return {
options: customers.map((customer) => ({ // these options will be shown to the user
label: customer.name, // user-friendly text for the option
value: customer.email, // usually an id, in this case not sure if there is an id or email for a customer
})),
context: { // this will be available as the prevContext variable in the next run (when user clicks load more on pipedream UI)
prevEndAt: endAt,
},
};
},
},
The GitHub projectV2
prop is a good example. As you can see you can also pass variables to async options()
if you need to (org and repo). The component that declares the prop can do it by passing it in the third argument in propDefinition
.
New Issue with Status source:
project: {
propDefinition: [
common.props.github,
"projectV2",
(c) => ({ // contains the previous prop values, both declared and inherited from common
org: c.org, // org prop value
repo: c.repo, // repo prop value
}),
],
},
The org
and repo
props are inherited from common-webhook-orgs.mjs.
Hi @ljdatasci, are you done with the changes? Is this ready for a PR review?
Hi @ljdatasci, are you done with the changes? Is this ready for a PR review?
@feyzullah The changes are done. Ready for PR review.
Hi @ljdatasci, thank you very much for your contribution. I added comments just for unnecessary code. We are almost done, can you please check?
@feyzullah The changes are done.