Skip to content
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.

Sign up for GitHub

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

feat: automatically publish newly created flows #639

Merged
merged 3 commits into from
Feb 3, 2025
Merged

feat: automatically publish newly created flows #639

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
5910a7d
createFlow also publishes
jessicamcinchak Jan 31, 2025
3c37d79
createFlow should accept optional userId
jessicamcinchak Jan 31, 2025
bd52807
correct args
jessicamcinchak Jan 31, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
77 changes: 47 additions & 30 deletions src/requests/flow.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,7 @@ export class FlowClient {
name: string;
data?: object;
status?: FlowStatus;
userId: number;
}): Promise<string> {
return createFlow(this.client, args);
}
Expand Down Expand Up @@ -148,48 +149,63 @@ export async function createFlow(
name: string;
data?: object;
status?: FlowStatus;
userId: number;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can also infer this from the JWT making the request - this might both avoid a lot of the associated cascading changes from adding this new argument, as well as ruling out an incorrect value being passed in.

If we just use "x-hasura-user-id" as a column preset, this will get read automatically from the JWT.

image

I'm pretty sure we can also toggle off access to the publisher_id column once this is configured as well to make sure no incorrect values get written in.

Docs: https://hasura.io/docs/2.0/auth/authorization/permissions/column-presets/

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good shout - here's my understanding of how this is currently handled:

  • e2e/tests/api-driven
    • globalHelpers all using $admin client (create user, create team, create flow) which is why we're manually passing around this userId
    • demo-workspace seems to be only exception to this which has uniquely defined/duplicated it's own createFlow mutaton. Strangely/incorrectly though, this is also the only variation of createFlow I've found which doesn't create an associated operation and therefore I haven't added initial publishing support either (the tests never cover either of these scenarios)
  • e2e/tests/ui-driven
    • /helpers/context similarly all using $admin client (create user, create team, create flow, update settings/integrations, etc)
    • There is a generateAuthenticationToken method in this subdir to make a JWT, but the only reference I can find to this is when we call it once via await browserContext.addCookies() - the future actions like creating a flow, updating flow status etc are still ultimately routed through an $admin client afaik

Column preset definitely feels like the right direction of travel here, but also feels like an expansive piece of tech debt bigger than publishing alone ??

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah similarly just been looking into this!

The column preset is a great solution for all real-life applications, but doesn't marry up to how we're creating flows in e2e environments (set up using $admin with no permissions, no user record associated via JWT).

I don't think making the userId param optional (for actual users) and conditionally reading argument or parsing from the JWT would make things any simpler - quite the opposite.

Agreed - this is a nice direction but a bigger change than I anticipated - this is a good route for now for sure ✅

},
): Promise<string> {
const response: { insert_flows_one: { id: string } } = await client.request(
gql`
mutation CreateFlow(
$teamId: Int!
$flowSlug: String!
$flowName: String!
$data: jsonb
$status: flow_status_enum_enum
) {
insert_flows_one(
object: {
team_id: $teamId
slug: $flowSlug
name: $flowName
data: $data
version: 1
status: $status
}
const response: { insert_flows_one: { id: string; data: object } } =
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My initial expectation was to destructure response into something like insert_flows_one: insertFlowResponse, but thinking about it more, do we keep response as is so it's easier to track variables in publishFlow lower down?

Crux of what I'm asking is, is it clearer to have:

  await publishFlow(client, {
    flow: {
      id: response.insert_flows_one.id,
      data: response.insert_flows_one.data,
    },
    publisherId: args.userId,
    summary: "Created flow",
  });

Or,

  await publishFlow(client, {
    flow: {
      id: insertFlowResponse.id,
      data: insertFlowResponse.data,
    },
    publisherId: args.userId,
    summary: "Created flow",
  });

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I simply extended the existing response pattern used throughout this file because I was only adding a single variable, either syntax would ultimately accomplish the same thing 👍

await client.request(
gql`
mutation CreateFlow(
$teamId: Int!
$flowSlug: String!
$flowName: String!
$data: jsonb
$status: flow_status_enum_enum
jessicamcinchak marked this conversation as resolved.
Show resolved Hide resolved
) {
id
insert_flows_one(
object: {
team_id: $teamId
slug: $flowSlug
name: $flowName
data: $data
version: 1
status: $status
}
) {
id
data
}
}
}
`,
{
teamId: args.teamId,
flowSlug: args.slug,
flowName: args.name,
data: args.data,
status: args.status || "offline",
},
);
`,
{
teamId: args.teamId,
flowSlug: args.slug,
flowName: args.name,
data: args.data,
status: args.status || "offline",
},
);
await createAssociatedOperation(client, {
flowId: response.insert_flows_one.id,
});
await publishFlow(client, {
flow: {
id: response.insert_flows_one.id,
data: response.insert_flows_one.data,
},
publisherId: args.userId,
summary: "Created flow",
});
return response.insert_flows_one.id;
}

export async function publishFlow(
client: GraphQLClient,
args: { flow: { id: string; data: object }; publisherId: number },
args: {
flow: { id: string; data: object };
publisherId: number;
summary?: string;
},
): Promise<number> {
const response: { insert_published_flows_one: { id: number } } =
await client.request(
Expand All @@ -207,6 +223,7 @@ export async function publishFlow(
flow_id: args.flow.id,
data: args.flow.data,
publisher_id: args.publisherId,
summary: args.summary,
},
},
);
Expand Down